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

[Albert Astals Cid]

El Dimarts, 6 d'agost de 2013, a les 00:43:57, Jaydeep Solanki va escriure:
> 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.

Why would you have 4 threads?

> 
> > > 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.

No, UI is blocked all the time, just a "small" amount of time usually, but 
it's still blocked.

> 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.

Errr, i fixed that a few weeks ago in 15eb104d75e3cd6cc22b958c994773af53f78ec0

Cheers,
  Albert

> 
> > 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