<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 8, 2013 at 2:25 AM, Albert Astals Cid <span dir="ltr"><<a href="mailto:aacid@kde.org" target="_blank">aacid@kde.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">El Dijous, 8 d'agost de 2013, a les 01:36:12, Jaydeep Solanki va escriure:<br>
<div>> On Thu, Aug 8, 2013 at 1:21 AM, Albert Astals Cid <<a href="mailto:aacid@kde.org" target="_blank">aacid@kde.org</a>> wrote:<br>
> > El Dijous, 8 d'agost de 2013, a les 01:09:27, Jaydeep Solanki va escriure:<br>
> > > Yes I know I have not took care of it here, I just wanted to show you<br>
> > > the<br>
> > > approach. And I still have no clue on how to delete the static object.<br>
> > > I tried QScopedPointer, it doesn't help<br>
> > ><br>
> > > And what to do with the clone method, I mean it's not virtual, can't<br>
> > > include EpubDocument because of circular dependency, then ?<br>
> > > Those were the two I can think of.<br>
> ><br>
> > Well, what's the point in fixing B if it needs A and you don't know how to<br>
> > fix<br>
> > A?<br>
><br>
> But don't you think both A and B in this case can be solved independently,<br>
> because if I first fix threading and then fix the cloning issue, I just<br>
> have to replace the name of the method.<br>
><br>
> For me it's totally okay, to fix resource loading issue first.<br>
><br>
> You have got any ideas, on how to avoid cyclic dependency and clone it ?<br>
<br>
</div>Why do you need to clone it</blockquote><div>I clone because I read it <a href="http://qt-project.org/doc/qt-4.8/threads-modules.html#threads-and-rich-text-processing">here</a>.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
, i'm still waiting for the answer to<br>
<div><br>
"Why would the UI thread have to wait?"<br></div></blockquote><div>it wouldn't have to wait if two different mutexes are used. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<br>
</div><span><font color="#888888">Albert<br>
</font></span><div><div><br>
><br>
> > Please concentrate on doing first things first.<br>
> ><br>
> > Cheers,<br>
> ><br>
> >   Albert<br>
> ><br>
> > > On Thu, Aug 8, 2013 at 12:57 AM, Albert Astals Cid <<a href="mailto:aacid@kde.org" target="_blank">aacid@kde.org</a>><br>
> ><br>
> > wrote:<br>
> > > > El Dijous, 8 d'agost de 2013, a les 00:37:42, Jaydeep Solanki va<br>
> ><br>
> > escriure:<br>
> > > > > I tried a lot of approaches for TextDocument threading and finally I<br>
> > > > > settled to a really simple approach (as it makes generator threaded<br>
> ><br>
> > as<br>
> ><br>
> > > > well<br>
> > > ><br>
> > > > > as gives best performance), diff attached.<br>
> > > > > I just want to ask, how to know when the document is closed and<br>
> ><br>
> > delete<br>
> ><br>
> > > > that<br>
> > > ><br>
> > > > > pointer, because now if I close a document and open another document<br>
> > > ><br>
> > > > images<br>
> > > ><br>
> > > > > displayed are of the previous document.<br>
> > > ><br>
> > > > How does this fix the incorrect loadResource being called?<br>
> > > ><br>
> > > > Cheers,<br>
> > > ><br>
> > > >   Albert<br>
> > > ><br>
> > > > > On Wed, Aug 7, 2013 at 6:11 AM, Fabio D'Urso <<a href="mailto:fabiodurso@hotmail.it" target="_blank">fabiodurso@hotmail.it</a>><br>
> > > ><br>
> > > > wrote:<br>
> > > > > > Hi,<br>
> > > > > ><br>
> > > > > > On Wednesday, August 07, 2013 12:31:41 AM Albert Astals Cid wrote:<br>
> > > > > > > El Dimarts, 6 d'agost de 2013, a les 20:52:25, Jaydeep Solanki<br>
> > > > > > > va<br>
> > > > > ><br>
> > > > > > escriure:<br>
> > > > > > > > Hi,<br>
> > > > > > > ><br>
> > > > > > > > I have implemented a simple Qt Visibility support, which hides<br>
> > > ><br>
> > > > text,<br>
> > > ><br>
> > > > > > it's<br>
> > > > > ><br>
> > > > > > > > doesn't hide the exact area of the text, because the way<br>
> > > ><br>
> > > > QTextDocument<br>
> > > ><br>
> > > > > > is<br>
> > > > > ><br>
> > > > > > > > developed it is impossible to implement an approach that hides<br>
> > > ><br>
> > > > only a<br>
> > > ><br>
> > > > > > part<br>
> > > > > ><br>
> > > > > > > > of line. Either we can hide a line or not hide it.<br>
> > > > > > > > And implementing an approach in which incrementing the cursor<br>
> ><br>
> > and<br>
> ><br>
> > > > not<br>
> > > ><br>
> > > > > > > > inserting the text was my idea, but it seems they are using<br>
> > > > > > > > the<br>
> > > ><br>
> > > > text<br>
> > > ><br>
> > > > > > > > so<br>
> > > > > > > > much that, I'm not able to get a way to exclude the text and<br>
> > > ><br>
> > > > implement<br>
> > > ><br>
> > > > > > > > visibility.<br>
> > > > > > ><br>
> > > > > > > Before continuing to work on that, i think you should explore<br>
> ><br>
> > with<br>
> ><br>
> > > > the<br>
> > > ><br>
> > > > > > > Qt<br>
> > > > > > > guys how feasible is this work to be accepted upstream with the<br>
> > > > > > > known<br>
> > > > > > > limitations you mention, because if it's not going to be<br>
> ><br>
> > accepted,<br>
> ><br>
> > > > it's<br>
> > > ><br>
> > > > > > not<br>
> > > > > ><br>
> > > > > > > really useful for us since we can't expect people to patch their<br>
> ><br>
> > Qt<br>
> ><br>
> > > > for<br>
> > > ><br>
> > > > > > us.<br>
> > > > > ><br>
> > > > > > > > Regarding the threaded QTextDocument, I tried the approach you<br>
> > > ><br>
> > > > said,<br>
> > > ><br>
> > > > > > and<br>
> > > > > ><br>
> > > > > > > > it<br>
> > > > > > > > seems that it is also blocking UI, even more then single<br>
> ><br>
> > threaded.<br>
> ><br>
> > > > > > Suppose<br>
> > > > > ><br>
> > > > > > > > I'm on a page and the next page is loading in other thread,<br>
> ><br>
> > the UI<br>
> ><br>
> > > > > > thread<br>
> > > > > ><br>
> > > > > > > > will have to wait till the other thread finishes it's job<br>
> ><br>
> > (because<br>
> ><br>
> > > > of<br>
> > > ><br>
> > > > > > > > locking), which takes a bit more time than usual because it is<br>
> > > > > ><br>
> > > > > > generated<br>
> > > > > ><br>
> > > > > > > > from a cloned QTextDocument.<br>
> > > > > > ><br>
> > > > > > > Why would the UI thread have to wait?<br>
> > > > > ><br>
> > > > > > Disclaimer: I haven't read the whole discussion, so this idea<br>
> > > > > > might<br>
> > > ><br>
> > > > not be<br>
> > > ><br>
> > > > > > applicable. If I understood correctly, there's some object that<br>
> ><br>
> > needs<br>
> ><br>
> > > > to<br>
> > > ><br>
> > > > > > be<br>
> > > > > > cloned because its methods are not reentrant, but cloning is<br>
> > > > > > expensive.<br>
> > > > > ><br>
> > > > > > I was thinking about keeping a pool of clones, initially<br>
> > > > > > containing<br>
> > > ><br>
> > > > only<br>
> > > ><br>
> > > > > > one<br>
> > > > > > instance, and adding a new clone to the pool when an instance is<br>
> > > ><br>
> > > > requested<br>
> > > ><br>
> > > > > > and<br>
> > > > > > there are no readily available ones.<br>
> > > > > ><br>
> > > > > > Of course this approach, if feasible at all, will waste memory.<br>
> > > ><br>
> > > > Depending<br>
> > > ><br>
> > > > > > on<br>
> > > > > > the size of the object it might pay or not.<br>
> > > > > ><br>
> > > > > > > > Regarding the clone method overriding in EpubDocument, I'm<br>
> ><br>
> > using a<br>
> ><br>
> > > > > > dynamic<br>
> > > > > ><br>
> > > > > > > > property, to store the name of the generator, and using it I<br>
> > > > > > > > decide<br>
> > > > > ><br>
> > > > > > which<br>
> > > > > ><br>
> > > > > > > > method to call EpubDocument::myClone() or<br>
> ><br>
> > QTextDocument::clone()<br>
> ><br>
> > > > > > > > in<br>
> > > > > > > > TextDocumentGenerator.<br>
> > > > > > ><br>
> > > > > > > You can't call EpubDocument::myClone in TextDocumentGenerator,<br>
> ><br>
> > that<br>
> ><br>
> > > > > > > introduces a circular dependency.<br>
> > > > > > ><br>
> > > > > > > > One more thing I noticed about Okular is it doesn't free up<br>
> > > > > > > > memory,<br>
> > > > > ><br>
> > > > > > after<br>
> > > > > ><br>
> > > > > > > > the document is closed, it frees after Okular quits, so my<br>
> > > ><br>
> > > > question is<br>
> > > ><br>
> > > > > > > > does<br>
> > > > > > > > it use the memory (cached pixmaps) when I load the same<br>
> ><br>
> > document<br>
> ><br>
> > > > again<br>
> > > ><br>
> > > > > > ?<br>
> > > > > ><br>
> > > > > > > Nope, it should free it, if it doesn't it's a bug that has to be<br>
> > > ><br>
> > > > fixed.<br>
> > > ><br>
> > > > > > I remember reading somewhere that most free() implementations<br>
> > > > > > don't<br>
> > > > > > actually<br>
> > > > > > return the memory back to the OS, instead they keep free'd blocks<br>
> ><br>
> > in a<br>
> ><br>
> > > > > > internal pool for future reuse. Eventually, when the process dies,<br>
> ><br>
> > all<br>
> ><br>
> > > > of<br>
> > > ><br>
> > > > > > its<br>
> > > > > > memory is reclaimed back by the OS.<br>
> > > > > ><br>
> > > > > > As Albert said, Okular does "free" pixmaps, but maybe you see that<br>
> > > > > > behavior<br>
> > > > > > for this reason.<br>
> > > > ><br>
> > > > > Makes sense.<br>
> > > > ><br>
> > > > > > > Cheers,<br>
> > > > > > ><br>
> > > > > > >   Albert<br>
> > > > > > ><br>
> > > > > > > > Cheers,<br>
> > > > > > > > Jaydeep<br>
> > > > > > ><br>
> > > > > > > _______________________________________________<br>
> > > > > > > Okular-devel mailing list<br>
> > > > > > > <a href="mailto:Okular-devel@kde.org" target="_blank">Okular-devel@kde.org</a><br>
> > > > > > > <a href="https://mail.kde.org/mailman/listinfo/okular-devel" target="_blank">https://mail.kde.org/mailman/listinfo/okular-devel</a><br>
> > > > > ><br>
> > > > > > --<br>
> > > > > > Fabio<br>
> > > > > ><br>
> > > > > > _______________________________________________<br>
> > > > > > Okular-devel mailing list<br>
> > > > > > <a href="mailto:Okular-devel@kde.org" target="_blank">Okular-devel@kde.org</a><br>
> > > > > > <a href="https://mail.kde.org/mailman/listinfo/okular-devel" target="_blank">https://mail.kde.org/mailman/listinfo/okular-devel</a><br>
> > > ><br>
> > > > _______________________________________________<br>
> > > > Okular-devel mailing list<br>
> > > > <a href="mailto:Okular-devel@kde.org" target="_blank">Okular-devel@kde.org</a><br>
> > > > <a href="https://mail.kde.org/mailman/listinfo/okular-devel" target="_blank">https://mail.kde.org/mailman/listinfo/okular-devel</a><br>
> ><br>
> > _______________________________________________<br>
> > Okular-devel mailing list<br>
> > <a href="mailto:Okular-devel@kde.org" target="_blank">Okular-devel@kde.org</a><br>
> > <a href="https://mail.kde.org/mailman/listinfo/okular-devel" target="_blank">https://mail.kde.org/mailman/listinfo/okular-devel</a><br>
<br>
_______________________________________________<br>
Okular-devel mailing list<br>
<a href="mailto:Okular-devel@kde.org" target="_blank">Okular-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/okular-devel" target="_blank">https://mail.kde.org/mailman/listinfo/okular-devel</a><br>
</div></div></blockquote></div><br></div></div>