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

Wed Aug 7 20:06:12 UTC 2013

On Thu, Aug 8, 2013 at 1:21 AM, Albert Astals Cid <aacid at kde.org> 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 ?

>
> Please concentrate on doing first things first.
>
> Cheers,
>   Albert
>
> >
> > 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
>
> _______________________________________________
> 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/9f931705/attachment-0001.html>