[webkit-qt] [RFC] Analysis on loading speed
Holger Hans Peter Freyther
zecke at selfish.org
Sun Dec 13 18:25:11 PST 2009
during the last couple of weeks (on an off) I tried to understand the loading
behavior of a specific website. In this case it was the english article about
the Maxwell Equations on Wikipedia.
We have two/three things playing together that make our loading speed
bad compared to other WebKit ports. The first thing is our HTTP network
stack. It is running in the GUI thread, on top of that the current API forces
to start the job only once we are back to the event loop. The next bit is
that we are spending a huge amount of time (1 second) on doing the layout
(harfbuzz, fontconfig) on this site and the last is that with the Qt Event
dispatcher more events are dispatched through one run through the eventloop
than with the glib one.
With the above let me explain what happens. Once we have downloaded
the CSS/JS WebCore will start to do the layout. We will block in layout
for the given second. During this time we block we will not send out any
HTTP requests, not finish/read anything...
The reason we block longer than other ports is that in Qt we always go
through the "complex" layout path and the way we use FontConfig is nice
for a general purpose GUI toolkit but might be overkill for a browser.
The options I see are the following:
1.) Move HTTP to a thread... I had a hacky implementation to move the
QNetworkAccessManager to a different thread but the QueuedConnection
implementation acorss threads seems to be not that fast. I have the
impression that the other thread waits until it is waking up anyway
(timeout on the select)
2.) Make harfbuzz and fontconfig fly. Specially in regard to harfbuzz it
seems unlikely that we can easily fix it.. in any case it is quite some work
on a component not understood by many.
3.) Implement Glyph API in Qt, or disable kerning (as Lars thinks is possible)
4.) What options do you guys see?
ideas greatly appreciated.
More information about the webkit-qt