El Divendres, 9 d'agost de 2013, a les 01:11:25, Jaydeep Solanki va escriure: > On Thu, Aug 8, 2013 at 2:25 AM, Albert Astals Cid <[email protected]> wrote: > > El Dijous, 8 d'agost de 2013, a les 01:36:12, Jaydeep Solanki va escriure: > > > On Thu, Aug 8, 2013 at 1:21 AM, Albert Astals Cid <[email protected]> wrote: > > > > El Dijous, 8 d'agost de 2013, a les 01:09:27, Jaydeep Solanki va > > > > escriure: > > > > > 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. > > > > > > > I tried QScopedPointer, it doesn't help > > > > > > > > > > And what to do with the clone method, I mean it's not virtual, can't > > > > > include EpubDocument because of circular dependency, then ? > > > > > Those were the two I can think of. > > > > > > > > Well, what's the point in fixing B if it needs A and you don't know > > > > how to > > > > > > fix > > > > A? > > > > > > 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. > > > > > > For me it's totally okay, to fix resource loading issue first. > > > > > > You have got any ideas, on how to avoid cyclic dependency and clone it ? > > > > Why do you need to clone it > > I clone because I read it > here<http://qt-project.org/doc/qt-4.8/threads-modules.html#threads-and-rich-> > text-processing> .
Ok, that's most probably a non issue nowadays when a QPixmap is basically thread friendly in almost most platforms, but ok. > > > , i'm still waiting for the answer to > > > > "Why would the UI thread have to wait?" > > it wouldn't have to wait if two different mutexes are used. If all the rendering is done in the second thread, why is the UI thread waiting for a mutex at all? Cheers, Albert > > > Albert > > > > > > Please concentrate on doing first things first. > > > > > > > > Cheers, > > > > > > > > Albert > > > > > > > > > On Thu, Aug 8, 2013 at 12:57 AM, Albert Astals Cid <[email protected]> > > > > > > > > wrote: > > > > > > El Dijous, 8 d'agost de 2013, a les 00:37:42, Jaydeep Solanki va > > > > > > > > escriure: > > > > > > > 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. > > > > > > > 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. > > > > > > > > > > > > How does this fix the incorrect loadResource being called? > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Albert > > > > > > > > > > > > > On Wed, Aug 7, 2013 at 6:11 AM, Fabio D'Urso < > > > > [email protected]> > > > > > > > > wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > On Wednesday, August 07, 2013 12:31:41 AM Albert Astals Cid > > > > wrote: > > > > > > > > > El Dimarts, 6 d'agost de 2013, a les 20:52:25, Jaydeep > > > > Solanki > > > > > > > > > > > va > > > > > > > > > > > > > > > > escriure: > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > I have implemented a simple Qt Visibility support, which > > > > hides > > > > > > > > text, > > > > > > > > > > > > > > it's > > > > > > > > > > > > > > > > > > doesn't hide the exact area of the text, because the way > > > > > > > > > > > > QTextDocument > > > > > > > > > > > > > > is > > > > > > > > > > > > > > > > > > developed it is impossible to implement an approach that > > > > hides > > > > > > > > only a > > > > > > > > > > > > > > part > > > > > > > > > > > > > > > > > > of line. Either we can hide a line or not hide it. > > > > > > > > > > And implementing an approach in which incrementing the > > > > cursor > > > > > > and > > > > > > > > > > not > > > > > > > > > > > > > > > > inserting the text was my idea, but it seems they are > > > > > > > > > > using > > > > > > > > > > the > > > > > > > > > > > > text > > > > > > > > > > > > > > > > so > > > > > > > > > > much that, I'm not able to get a way to exclude the text > > > > and > > > > > > > > implement > > > > > > > > > > > > > > > > visibility. > > > > > > > > > > > > > > > > > > Before continuing to work on that, i think you should > > > > > > > > > explore > > > > > > > > with > > > > > > > > > > the > > > > > > > > > > > > > > > Qt > > > > > > > > > guys how feasible is this work to be accepted upstream with > > > > the > > > > > > > > > > > known > > > > > > > > > limitations you mention, because if it's not going to be > > > > > > > > accepted, > > > > > > > > > > it's > > > > > > > > > > > > > > not > > > > > > > > > > > > > > > > > really useful for us since we can't expect people to patch > > > > their > > > > > > Qt > > > > > > > > > > for > > > > > > > > > > > > > > us. > > > > > > > > > > > > > > > > > > Regarding the threaded QTextDocument, I tried the approach > > > > you > > > > > > > > said, > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > > > it > > > > > > > > > > seems that it is also blocking UI, even more then single > > > > > > > > threaded. > > > > > > > > > > > > Suppose > > > > > > > > > > > > > > > > > > I'm on a page and the next page is loading in other > > > > > > > > > > thread, > > > > > > > > the UI > > > > > > > > > > > > thread > > > > > > > > > > > > > > > > > > will have to wait till the other thread finishes it's job > > > > > > > > (because > > > > > > > > > > of > > > > > > > > > > > > > > > > locking), which takes a bit more time than usual because > > > > it is > > > > > > > > > > generated > > > > > > > > > > > > > > > > > > from a cloned QTextDocument. > > > > > > > > > > > > > > > > > > Why would the UI thread have to wait? > > > > > > > > > > > > > > > > Disclaimer: I haven't read the whole discussion, so this idea > > > > > > > > might > > > > > > > > > > > > not be > > > > > > > > > > > > > > applicable. If I understood correctly, there's some object > > > > > > > > that > > > > > > > > needs > > > > > > > > > > to > > > > > > > > > > > > > > be > > > > > > > > cloned because its methods are not reentrant, but cloning is > > > > > > > > expensive. > > > > > > > > > > > > > > > > I was thinking about keeping a pool of clones, initially > > > > > > > > containing > > > > > > > > > > > > only > > > > > > > > > > > > > > one > > > > > > > > instance, and adding a new clone to the pool when an instance > > > > is > > > > > > > > requested > > > > > > > > > > > > > > and > > > > > > > > there are no readily available ones. > > > > > > > > > > > > > > > > Of course this approach, if feasible at all, will waste > > > > > > > > memory. > > > > > > > > > > > > Depending > > > > > > > > > > > > > > on > > > > > > > > the size of the object it might pay or not. > > > > > > > > > > > > > > > > > > Regarding the clone method overriding in EpubDocument, I'm > > > > > > > > using a > > > > > > > > > > > > dynamic > > > > > > > > > > > > > > > > > > property, to store the name of the generator, and using it > > > > I > > > > > > > > > > > > decide > > > > > > > > > > > > > > > > which > > > > > > > > > > > > > > > > > > method to call EpubDocument::myClone() or > > > > > > > > QTextDocument::clone() > > > > > > > > > > > > > > in > > > > > > > > > > TextDocumentGenerator. > > > > > > > > > > > > > > > > > > You can't call EpubDocument::myClone in > > > > TextDocumentGenerator, > > > > > > that > > > > > > > > > > > > > introduces a circular dependency. > > > > > > > > > > > > > > > > > > > One more thing I noticed about Okular is it doesn't free > > > > > > > > > > up > > > > > > > > > > memory, > > > > > > > > > > > > > > > > after > > > > > > > > > > > > > > > > > > the document is closed, it frees after Okular quits, so my > > > > > > > > > > > > question is > > > > > > > > > > > > > > > > does > > > > > > > > > > it use the memory (cached pixmaps) when I load the same > > > > > > > > document > > > > > > > > > > again > > > > > > > > > > > > > > ? > > > > > > > > > > > > > > > > > Nope, it should free it, if it doesn't it's a bug that has > > > > to be > > > > > > > > fixed. > > > > > > > > > > > > > > I remember reading somewhere that most free() implementations > > > > > > > > don't > > > > > > > > actually > > > > > > > > return the memory back to the OS, instead they keep free'd > > > > blocks > > > > > > in a > > > > > > > > > > > > internal pool for future reuse. Eventually, when the process > > > > dies, > > > > > > all > > > > > > > > > > of > > > > > > > > > > > > > > its > > > > > > > > memory is reclaimed back by the OS. > > > > > > > > > > > > > > > > As Albert said, Okular does "free" pixmaps, but maybe you see > > > > that > > > > > > > > > > behavior > > > > > > > > for this reason. > > > > > > > > > > > > > > Makes sense. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > > > Albert > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Jaydeep > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Okular-devel mailing list > > > > > > > > > [email protected] > > > > > > > > > https://mail.kde.org/mailman/listinfo/okular-devel > > > > > > > > > > > > > > > > -- > > > > > > > > Fabio > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Okular-devel mailing list > > > > > > > > [email protected] > > > > > > > > https://mail.kde.org/mailman/listinfo/okular-devel > > > > > > > > > > > > _______________________________________________ > > > > > > Okular-devel mailing list > > > > > > [email protected] > > > > > > https://mail.kde.org/mailman/listinfo/okular-devel > > > > > > > > _______________________________________________ > > > > Okular-devel mailing list > > > > [email protected] > > > > https://mail.kde.org/mailman/listinfo/okular-devel > > > > _______________________________________________ > > Okular-devel mailing list > > [email protected] > > https://mail.kde.org/mailman/listinfo/okular-devel _______________________________________________ Okular-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/okular-devel
