<div dir="ltr">yes it won't wait<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 9, 2013 at 1:33 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 Divendres, 9 d'agost de 2013, a les 01:11:25, Jaydeep Solanki va escriure:<br>
<div><div class="h5">> On Thu, Aug 8, 2013 at 2:25 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 01:36:12, Jaydeep Solanki va escriure:<br>
> > > On Thu, Aug 8, 2013 at 1:21 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 01:09:27, Jaydeep Solanki va<br>
> ><br>
> > escriure:<br>
> > > > > Yes I know I have not took care of it here, I just wanted to show<br>
> > > > > you<br>
> > > > > the<br>
> > > > > approach. And I still have no clue on how to delete the static<br>
> ><br>
> > object.<br>
> ><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<br>
> ><br>
> > how to<br>
> ><br>
> > > > fix<br>
> > > > A?<br>
> > ><br>
> > > But don't you think both A and B in this case can be solved<br>
> ><br>
> > independently,<br>
> ><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>
> > Why do you need to clone it<br>
><br>
> I clone because I read it<br>
</div></div>> here<<a href="http://qt-project.org/doc/qt-4.8/threads-modules.html#threads-and-rich-" target="_blank">http://qt-project.org/doc/qt-4.8/threads-modules.html#threads-and-rich-</a>> text-processing> .<br>

<br>
Ok, that's most probably a non issue nowadays when a QPixmap is basically<br>
thread friendly in almost most platforms, but ok.<br>
<div class="im"><br>
><br>
> > , i'm still waiting for the answer to<br>
> ><br>
> > "Why would the UI thread have to wait?"<br>
><br>
> it wouldn't have to wait if two different mutexes are used.<br>
<br>
</div>If all the rendering is done in the second thread, why is the UI thread<br>
waiting for a mutex at all?<br>
<br>
Cheers,<br>
  Albert<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> > Albert<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">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<br>
> ><br>
> > finally I<br>
> ><br>
> > > > > > > settled to a really simple approach (as it makes generator<br>
> ><br>
> > 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<br>
> ><br>
> > 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 <<br>
> ><br>
> > <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<br>
> ><br>
> > wrote:<br>
> > > > > > > > > El Dimarts, 6 d'agost de 2013, a les 20:52:25, Jaydeep<br>
> ><br>
> > Solanki<br>
> ><br>
> > > > > > > > > va<br>
> > > > > > > ><br>
> > > > > > > > escriure:<br>
> > > > > > > > > > Hi,<br>
> > > > > > > > > ><br>
> > > > > > > > > > I have implemented a simple Qt Visibility support, which<br>
> ><br>
> > 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<br>
> ><br>
> > 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<br>
> ><br>
> > cursor<br>
> ><br>
> > > > and<br>
> > > ><br>
> > > > > > not<br>
> > > > > ><br>
> > > > > > > > > > inserting the text was my idea, but it seems they are<br>
> > > > > > > > > > using<br>
> > > > > > > > > > the<br>
> > > > > ><br>
> > > > > > text<br>
> > > > > ><br>
> > > > > > > > > > so<br>
> > > > > > > > > > much that, I'm not able to get a way to exclude the text<br>
> ><br>
> > and<br>
> ><br>
> > > > > > implement<br>
> > > > > ><br>
> > > > > > > > > > visibility.<br>
> > > > > > > > ><br>
> > > > > > > > > Before continuing to work on that, i think you should<br>
> > > > > > > > > explore<br>
> > > ><br>
> > > > with<br>
> > > ><br>
> > > > > > the<br>
> > > > > ><br>
> > > > > > > > > Qt<br>
> > > > > > > > > guys how feasible is this work to be accepted upstream with<br>
> ><br>
> > the<br>
> ><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<br>
> ><br>
> > their<br>
> ><br>
> > > > Qt<br>
> > > ><br>
> > > > > > for<br>
> > > > > ><br>
> > > > > > > > us.<br>
> > > > > > > ><br>
> > > > > > > > > > Regarding the threaded QTextDocument, I tried the approach<br>
> ><br>
> > 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<br>
> > > > > > > > > > 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<br>
> ><br>
> > 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<br>
> > > > > > > > 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<br>
> ><br>
> > 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<br>
> > > > > > > > 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<br>
> ><br>
> > I<br>
> ><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<br>
> ><br>
> > TextDocumentGenerator,<br>
> ><br>
> > > > that<br>
> > > ><br>
> > > > > > > > > introduces a circular dependency.<br>
> > > > > > > > ><br>
> > > > > > > > > > One more thing I noticed about Okular is it doesn't free<br>
> > > > > > > > > > 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<br>
> ><br>
> > 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<br>
> ><br>
> > blocks<br>
> ><br>
> > > > in a<br>
> > > ><br>
> > > > > > > > internal pool for future reuse. Eventually, when the process<br>
> ><br>
> > 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<br>
> ><br>
> > that<br>
> ><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>
> ><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>