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

[Jaydeep Solanki]

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 <fabiodurso at hotmail.it> 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
> > Okular-devel at kde.org
> > https://mail.kde.org/mailman/listinfo/okular-devel
>
> --
> Fabio
>
> _______________________________________________
> Okular-devel mailing list
> Okular-devel at kde.org
> https://mail.kde.org/mailman/listinfo/okular-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/okular-devel/attachments/20130808/63cbffe5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TxtDocThread.diff
Type: application/octet-stream
Size: 800 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/okular-devel/attachments/20130808/63cbffe5/attachment-0001.obj>