[Webkit-unassigned] [Bug 35652] New: [Qt] Webkit resize is really slow.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=35652

           Summary: [Qt] Webkit resize is really slow.
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Other
        OS/Version: Mac OS X 10.5
            Status: NEW
          Keywords: Qt
          Severity: Normal
          Priority: P2
         Component: New Bugs
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: vestbo at webkit.org


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.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.