[Qt] Webkit resize is really slow.

• Component: New Bugs
• Status: RESOLVED DUPLICATE

[Tor Arne Vestbø]

This bug report originated from issue QTBUG-5929
http://bugreports.qt.nokia.com/browse/QTBUG-5929

--- Description ---

In 4.6.0RC release build Qt Assistant is nearly impossible to use while trying to re-size the window. Also jumping to an anchor is dead slow. The same got reported on qt4-preview for OSX. This might be related to the batch of webkit merges done before the RC. Please also note when I build Qt Assistant using QTextBrowser the bad behavior isn't observed. 

--- Comments ---

Was also observed in 4.6 beta1.

We see the same with the help in Qt Creator. Profile data (Mac Activity Monitor's "Sample Process" button) for doing a context help (F1) on QObject is attached.

I can also reproduce this on a linux x86_64 system w/ latest nvidia binary driver. So it's definitely a platform independend issue.

We had a look at the issue and there is no precise bottle neck.
Most of the execution time of resizes is spent in QTextLine/QTextEngine and its not something that was blazzingly fast in 4.5 neither (though it was faster).

It's something that require much investigation and work so we'll have a look at it for 4.6.1.

The slow anchor jumping and the 10 seconds page loading is more critical in my opinion but we could not reproduce it on any of our workstation here (it takes around 4 seconds to finish loading QString doc from the disk or network).
This is however another issue, I filled a bug there https://bugs.webkit.org/show_bug.cgi?id=31719
Please fill it with other details that could help reproducing the problem.

Note that browsers based on webkit such as Chrome or Safari don't have this problem. Actually, it's almost instantaneous to browse "http://doc.trolltech.com/4.6/qwidget.html" with these browsers, while it is slower to use Assistant with the help located on my HD. In both cases, no slow anchor or resize.
You say it takes "around 4 seconds to finish loading QString doc from the disk". Here it takes 2 seconds (fast machine), but that does not seem correct to me. One could reasonably expect local browsing to be almost instantaneous on a fast system when displaying rather simple pages (even long ones), as it was with the old Assistant version (I mean the version without webkit, prior to 4.5; 4.5 was faster than 4.6, but much slower than 4.4).

Wasn't this supposed to be "looked at" for Qt 4.6.1? It was just released and I see zero improvement.

Yes, no change in 4.6.1. It's funny to see that the Assistant "Print Preview" does not have this problem and is as fast as one would expect!

I have noticed problems with resizing of the webkit frame, as well as things like scrolling and using css resize. When I attempt this in Safari or Chrome, its blazingly fast, but it lags in Qt.

An example of what I'm talking about can be seen by opening this page in Safari and also in Qt. Hopefully this will help you find the bug.

http://gist.github.com/288082

I had a look at this with a profiler, Rational Quantify. I started the browser demo loading QString doc page from my hard disk.

About one quarter of the main thread's run time is spent in Windows' GetGlyphOutlineW. Could we replace this with something faster? When I try the same with Firefox, this function doesn't seem to be called at all.

Call flow is as follows:

...
QTextLine::setLineWidth
QTextLine::layout_helper
QFontEngineMulti::boundingBox
QFontEngineWin::boundingBox
QFontEngineWin::boundingBox
QFontEngineWin::getOutlineMetrics
GetGlyphOutlineW

If I missed something or should give more information just tell me.

I'd also like to note that performance is worst on Windows machines. For a very large HTML file with source and images all on disk, rendering time on Win7 x64 is 45 seconds, but the same file renders in 2 seconds in the same application on Kubuntu Karmic x64. Granted, the second machine is slightly more powerful, but not 20+ times.

[Tor Arne Vestbø]

Possibly related to bug #20054

[Benjamin Poulain]

*** This bug has been marked as a duplicate of bug 31719 ***