On Mon, Aug 5, 2013 at 12:25 AM, Albert Astals Cid <aa...@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@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