<div dir="ltr"><div><div>Yes I know I have not took care of it here, I just wanted to show you the approach. And I still have no clue on how to delete the static object.<br></div><div>I tried QScopedPointer, it doesn't help<br>
</div><div><br></div>And what to do with the clone method, I mean it's not virtual, can't include EpubDocument because of circular dependency, then ?<br></div><div>Those were the two I can think of.<br></div><br></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 8, 2013 at 12:57 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 00:37:42, Jaydeep Solanki va escriure:<br>
<div class="im">> I tried a lot of approaches for TextDocument threading and finally I<br>
> settled to a really simple approach (as it makes generator threaded as well<br>
> as gives best performance), diff attached.<br>
> I just want to ask, how to know when the document is closed and delete that<br>
> pointer, because now if I close a document and open another document images<br>
> displayed are of the previous document.<br>
<br>
</div>How does this fix the incorrect loadResource being called?<br>
<br>
Cheers,<br>
  Albert<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> On Wed, Aug 7, 2013 at 6:11 AM, Fabio D'Urso <<a href="mailto:fabiodurso@hotmail.it">fabiodurso@hotmail.it</a>> 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 va<br>
> ><br>
> > escriure:<br>
> > > > Hi,<br>
> > > ><br>
> > > > I have implemented a simple Qt Visibility support, which hides text,<br>
> ><br>
> > it's<br>
> ><br>
> > > > doesn't hide the exact area of the text, because the way QTextDocument<br>
> ><br>
> > is<br>
> ><br>
> > > > developed it is impossible to implement an approach that hides 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 and not<br>
> > > > inserting the text was my idea, but it seems they are using the text<br>
> > > > so<br>
> > > > much that, I'm not able to get a way to exclude the text and implement<br>
> > > > visibility.<br>
> > ><br>
> > > Before continuing to work on that, i think you should explore with the<br>
> > > Qt<br>
> > > guys how feasible is this work to be accepted upstream with the known<br>
> > > limitations you mention, because if it's not going to be accepted, it's<br>
> ><br>
> > not<br>
> ><br>
> > > really useful for us since we can't expect people to patch their Qt for<br>
> ><br>
> > us.<br>
> ><br>
> > > > Regarding the threaded QTextDocument, I tried the approach you said,<br>
> ><br>
> > and<br>
> ><br>
> > > > it<br>
> > > > seems that it is also blocking UI, even more then single threaded.<br>
> ><br>
> > Suppose<br>
> ><br>
> > > > I'm on a page and the next page is loading in other thread, the UI<br>
> ><br>
> > thread<br>
> ><br>
> > > > will have to wait till the other thread finishes it's job (because of<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 might not be<br>
> > applicable. If I understood correctly, there's some object that needs to<br>
> > be<br>
> > cloned because its methods are not reentrant, but cloning is expensive.<br>
> ><br>
> > I was thinking about keeping a pool of clones, initially containing only<br>
> > one<br>
> > instance, and adding a new clone to the pool when an instance is requested<br>
> > and<br>
> > there are no readily available ones.<br>
> ><br>
> > Of course this approach, if feasible at all, will waste memory. Depending<br>
> > on<br>
> > the size of the object it might pay or not.<br>
> ><br>
> > > > Regarding the clone method overriding in EpubDocument, I'm using a<br>
> ><br>
> > dynamic<br>
> ><br>
> > > > property, to store the name of the generator, and using it I decide<br>
> ><br>
> > which<br>
> ><br>
> > > > method to call EpubDocument::myClone() or QTextDocument::clone() in<br>
> > > > TextDocumentGenerator.<br>
> > ><br>
> > > You can't call EpubDocument::myClone in TextDocumentGenerator, that<br>
> > > introduces a circular dependency.<br>
> > ><br>
> > > > One more thing I noticed about Okular is it doesn't free up memory,<br>
> ><br>
> > after<br>
> ><br>
> > > > the document is closed, it frees after Okular quits, so my question is<br>
> > > > does<br>
> > > > it use the memory (cached pixmaps) when I load the same document again<br>
> ><br>
> > ?<br>
> ><br>
> > > Nope, it should free it, if it doesn't it's a bug that has to be fixed.<br>
> ><br>
> > I remember reading somewhere that most free() implementations don't<br>
> > actually<br>
> > return the memory back to the OS, instead they keep free'd blocks in a<br>
> > internal pool for future reuse. Eventually, when the process dies, all of<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">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">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">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>