Re: [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  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@kde.org
> > https://mail.kde.org/mailman/listinfo/okular-devel

___
Okular-devel mailing list
Okular-devel@kde.org
https://mail.kde.org/mailman/listinfo/okular-devel

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

[Jaydeep Solanki]

On Mon, Aug 5, 2013 at 12:25 AM, Albert Astals Cid  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@kde.org
> https://mail.kde.org/mailman/listinfo/okular-devel
>


TxtDoc_THread.diff
Description: Binary data
___
Okular-devel mailing list
Okular-devel@kde.org
https://mail.kde.org/mailman/listinfo/okular-devel

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

[Albert Astals Cid]

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?

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

Cheers,
  Albert

> 
> Note: I used QElapsedTimer to get the estimated time.
> 
> Cheers,
> Jaydeep

___
Okular-devel mailing list
Okular-devel@kde.org
https://mail.kde.org/mailman/listinfo/okular-devel

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

[Jaydeep Solanki]

And for the comparisons, I have Intel i5-2430M
Processor


On Sun, Aug 4, 2013 at 11:31 PM, Jaydeep Solanki  wrote:

> 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.
>
> 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.
>
> 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.
>
> Note: I used QElapsedTimer to get the estimated time.
>
> Cheers,
> Jaydeep
>
___
Okular-devel mailing list
Okular-devel@kde.org
https://mail.kde.org/mailman/listinfo/okular-devel