<div dir="ltr"><div><div>I tried a lot of approaches for TextDocument threading and finally I settled to a really simple approach (as it makes generator threaded as well as gives best performance), diff attached.<br></div>
I just want to ask, how to know when the document is closed and delete that pointer, because now if I close a document and open another document images displayed are of the previous document.<br></div><div><div><div><div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 7, 2013 at 6:11 AM, Fabio D'Urso <span dir="ltr"><<a href="mailto:fabiodurso@hotmail.it" target="_blank">fabiodurso@hotmail.it</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<div class="im"><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 escriure:<br>
> > Hi,<br>
> ><br>
> > I have implemented a simple Qt Visibility support, which hides text, it's<br>
> > doesn't hide the exact area of the text, because the way QTextDocument is<br>
> > developed it is impossible to implement an approach that hides only a part<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 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 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 not<br>
> really useful for us since we can't expect people to patch their Qt for us.<br>
><br>
> > Regarding the threaded QTextDocument, I tried the approach you said, and<br>
> > it<br>
> > seems that it is also blocking UI, even more then single threaded. Suppose<br>
> > I'm on a page and the next page is loading in other thread, the UI thread<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 generated<br>
> > from a cloned QTextDocument.<br>
><br>
> Why would the UI thread have to wait?<br>
<br>
</div>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 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 one<br>
instance, and adding a new clone to the pool when an instance is requested and<br>
there are no readily available ones.<br>
<br>
Of course this approach, if feasible at all, will waste memory. Depending on<br>
the size of the object it might pay or not.<br>
<div class="im"><br>
> > Regarding the clone method overriding in EpubDocument, I'm using a dynamic<br>
> > property, to store the name of the generator, and using it I decide which<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, after<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>
> Nope, it should free it, if it doesn't it's a bug that has to be fixed.<br>
<br>
</div>I remember reading somewhere that most free() implementations don't 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 its<br>
memory is reclaimed back by the OS.<br>
<br>
As Albert said, Okular does "free" pixmaps, but maybe you see that behavior<br>
for this reason.<br></blockquote><div>Makes sense. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> Cheers,<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>
</div>--<br>
Fabio<br>
<div class="HOEnZb"><div class="h5"><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></div></div></div></div></div>