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

[Jaydeep Solanki]

On Mon, Aug 5, 2013 at 12:25 AM, Albert Astals Cid <aacid at kde.org> wrote:

> El Diumenge, 4 d'agost de 2013, a les 23:31:02, Jaydeep Solanki va
> escriure:
> > Hi,
> >
> > Regarding the TextDocument threaded rendering issue, I implemented a
> clone
> > method to return an EpubDocument. QTextDocument::clone() is not a virtual
> > method, so either we'll have to make it virtual or change the signature
> of
> > clone method in EpubDocument.
> > I made QTextDocument::clone() virtual.
>
> You can't do that. It will change the ABI of Qt and that's simply not
> acceptable.
>
> > It worked fine, but despite of all the optimizations I can do, it takes
> > around 400 to 500 ms to clone & 600 - 700 ms to draw, which is huge! I
> > checked QTextDocument::clone() it is a bit faster (because it has direct
> > access to the private classes), but won't make any difference.
> >
> > To make it even faster I tried it without cloning ( kept mutex locking ),
> > it takes around 200 to 500ms, still bad. Finally, to get an estimate
> about
> > what it takes without threading, I tried the non-threaded version, & to
> my
> > surprise it broke all records 0 to 100ms depending on the content.
>
> That is weird, why would locking take 400ms?
>
That's for the worst case, suppose for 4 threads, 1st thread draws other
all wait, 2nd draws, 3rd and 4th wait, then 3rd draws and 4th waits. Now
4th gets a change, which will accumulate a lot of time spent waiting.

>
> > Here I learnt one thing, drawing from a just cloned QTextDocument takes
> > more time, and I guess that's because of the cachedResources.
> >
> > I even tried QAtomicPointer, but it breaks at several places.
> >
> > I tried a lot to make it work faster, because I know you have announced
> it
> > in Acadamy that Okular will be getting threaded rendering for
> > QTextDocument, but may be for now it is better to leave it single
> threaded.
>
> Don't worry, It was a BoF with around 5 people. If it can't be done, it
> can't
> be done.
>
> *BUT* on the other hand even having a slower version that is thread is
> interesting since it means the UI doesn't get blocked. We may think if it
> makes sense to do the "viewport requests" in the UI thread for the speed
> and
> the "preloading requests" in the non-UI thread for UI smoothness.
>
UI will only be blocked when Okular is on Greedy Performance and it's a
single threaded generator. So instead of making it support threading I
think it would be better to decrease the performance (i.e. from Greedy to
Normal) for single threaded generators.
This way we won't encounter a UI blocking situation and will also get the
benefit of not having the overhead of locking.
I have attached a patch.

>
> Cheers,
>   Albert
>
> >
> > Note: I used QElapsedTimer to get the estimated time.
> >
> > Cheers,
> > Jaydeep
>
> _______________________________________________
> 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/20130806/7419ae5c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TxtDoc_THread.diff
Type: application/octet-stream
Size: 6686 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/okular-devel/attachments/20130806/7419ae5c/attachment.obj>