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.
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 >
TxtDocThread.diff
Description: Binary data
_______________________________________________ Okular-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/okular-devel
