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