<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 5, 2013 at 12:25 AM, Albert Astals Cid <span dir="ltr"><<a href="mailto:aacid@kde.org" target="_blank">aacid@kde.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">El Diumenge, 4 d'agost de 2013, a les 23:31:02, Jaydeep Solanki va escriure:<br>
<div class="im">> Hi,<br>
><br>
> Regarding the TextDocument threaded rendering issue, I implemented a clone<br>
> method to return an EpubDocument. QTextDocument::clone() is not a virtual<br>
> method, so either we'll have to make it virtual or change the signature of<br>
> clone method in EpubDocument.<br>
> I made QTextDocument::clone() virtual.<br>
<br>
</div>You can't do that. It will change the ABI of Qt and that's simply not<br>
acceptable.<br>
<div class="im"><br>
> It worked fine, but despite of all the optimizations I can do, it takes<br>
> around 400 to 500 ms to clone & 600 - 700 ms to draw, which is huge! I<br>
> checked QTextDocument::clone() it is a bit faster (because it has direct<br>
> access to the private classes), but won't make any difference.<br>
><br>
> To make it even faster I tried it without cloning ( kept mutex locking ),<br>
> it takes around 200 to 500ms, still bad. Finally, to get an estimate about<br>
> what it takes without threading, I tried the non-threaded version, & to my<br>
> surprise it broke all records 0 to 100ms depending on the content.<br>
<br>
</div>That is weird, why would locking take 400ms?<br></blockquote><div>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. <br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> Here I learnt one thing, drawing from a just cloned QTextDocument takes<br>
> more time, and I guess that's because of the cachedResources.<br>
><br>
> I even tried QAtomicPointer, but it breaks at several places.<br>
><br>
> I tried a lot to make it work faster, because I know you have announced it<br>
> in Acadamy that Okular will be getting threaded rendering for<br>
> QTextDocument, but may be for now it is better to leave it single threaded.<br>
<br>
</div>Don't worry, It was a BoF with around 5 people. If it can't be done, it can't<br>
be done.<br>
<br>
*BUT* on the other hand even having a slower version that is thread is<br>
interesting since it means the UI doesn't get blocked. We may think if it<br>
makes sense to do the "viewport requests" in the UI thread for the speed and<br>
the "preloading requests" in the non-UI thread for UI smoothness.<br></blockquote><div>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.<br>
</div><div>This way we won't encounter a UI blocking situation and will also get the benefit of not having the overhead of locking.<br></div><div>I have attached a patch.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Cheers,<br>
  Albert<br>
<div class="im"><br>
><br>
> Note: I used QElapsedTimer to get the estimated time.<br>
><br>
> Cheers,<br>
> Jaydeep<br>
<br>
</div>_______________________________________________<br>
Okular-devel mailing list<br>
<a href="mailto:Okular-devel@kde.org">Okular-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/okular-devel" target="_blank">https://mail.kde.org/mailman/listinfo/okular-devel</a><br>
</blockquote></div><br></div></div>