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

Wed Aug 7 19:39:27 UTC 2013

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.

On Thu, Aug 8, 2013 at 12:57 AM, Albert Astals Cid <aacid at kde.org> 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 <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
>
> _______________________________________________
> 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/d1b15d25/attachment.html>