<div dir="ltr">And for the comparisons, I have <a href="http://ark.intel.com/products/53450">Intel i5-2430M Processor</a><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Aug 4, 2013 at 11:31 PM, Jaydeep Solanki <span dir="ltr"><<a href="mailto:jaydp17@gmail.com" target="_blank">jaydp17@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Hi,<br><br></div>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.<br>

</div><div>I made QTextDocument::clone() virtual.<br><br></div><div>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.<br>

<br></div><div>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.<br>

<br>Here I learnt one thing, drawing from a just cloned QTextDocument takes more time, and I guess that's because of the cachedResources.<br><br></div><div>I even tried QAtomicPointer, but it breaks at several places.<br>

</div><div><br></div><div>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.<br>

<br></div><div>Note: I used QElapsedTimer to get the estimated time.<br><br>Cheers,<br>Jaydeep<br></div></div></div>
</blockquote></div><br></div>