[Okular-devel] Dt. 6th August - status

[Fabio D'Urso]

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.

> Cheers,
>   Albert
> 
> > Cheers,
> > Jaydeep
> 
> _______________________________________________
> Okular-devel mailing list
> Okular-devel at kde.org
> https://mail.kde.org/mailman/listinfo/okular-devel

--
Fabio