<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 8, 2013 at 1:21 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:09:27, Jaydeep Solanki va escriure:<br>
<div class="im">> Yes I know I have not took care of it here, I just wanted to show you 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>
</div>Well, what's the point in fixing B if it needs A and you don't know how to fix<br>
A?<br></blockquote><div>But don't you think both A and B in this case can be solved independently, because if I first fix threading and then fix the cloning issue, I just have to replace the name of the method.<br><br>
</div><div>For me it's totally okay, to fix resource loading issue first.<br></div><div><br></div><div>You have got any ideas, on how to avoid cyclic dependency and clone it ?<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Please concentrate on doing first things first.<br>
<br>
Cheers,<br>
  Albert<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> On Thu, Aug 8, 2013 at 12:57 AM, Albert Astals Cid <<a href="mailto:aacid@kde.org">aacid@kde.org</a>> wrote:<br>
> > El Dijous, 8 d'agost de 2013, a les 00:37:42, Jaydeep Solanki va 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 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 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">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 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 and<br>
> ><br>
> > not<br>
> ><br>
> > > > > > inserting the text was my idea, but it seems they are using 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 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 accepted,<br>
> ><br>
> > it's<br>
> ><br>
> > > > not<br>
> > > ><br>
> > > > > really useful for us since we can't expect people to patch their 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 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<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 might<br>
> ><br>
> > not be<br>
> ><br>
> > > > applicable. If I understood correctly, there's some object that 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 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 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 QTextDocument::clone()<br>
> > > > > > 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<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 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 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<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">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>
<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>