[webkit-qt] [RFC] Analysis on loading speed

[Holger Hans Peter Freyther]

Lars Knoll <lars.knoll <at> nokia.com> writes:



> The current situation is bad, as we wait until we're back in the event loop 
> before starting the request. This might cause a DNS lookup that will give us 
> one more round through the event loop. Worst case we loose a few seconds with 
> this.

Peter Hartmann and Markus Götz were discussion what they can do immediately.
With the current API we need to through the event loop to be able to connect
signals but they thought about starting GET requests immediately or such.




> 
> > 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.
> 
> We should look at it again, maybe there's a regression/bug somewhere in font 
> loading or harfbuzz.

I have no idea if it is possible but improving font loading (I assume this
includes opening and loading the OpenType table) could help us to speed
things up and to save some memory.


> But apart from that it'll be hard to speed this up significantly. I've spend a 
> significant amount of time three years back optimising harfbuzz as much as 
> possible.

I have created a test case that is using QFont like we use it when loading
the Maxwell Equations, I will do something like this for text rendering and
layout as well to make us have reproducable test cases (but probably
only by next month as my time on WebKit is up).




> 
> We could try disabling OpenType shaping and kerning for latin fonts, but we 
> will then run the risk that we hide issues occurring with non latin writing 
> systems (as we don't usually test these). In addition, it'll reduce the 
> quality of text layouting.

> Disabling kerning is easy. See QFont::setKerning(). In addition, you could try 
> disabling font merging (QFont::setStyleStrategy(QFont::NoFontMerging)). How 
> much does that make a difference?

I was using QFont::setKerning(false) but couldn't see anything noticable, I
will have to try with NoFontMerging as well. For a proper implementation
we can rely on WebCore's Font.cpp to decide if we can use the fast path or
not.


> 
> Implementing the Glyph API is some more work, and I think Simon and myself 
> once decided that the benefits are probably small. IIRC the Glyph API only 
> works for Latin and without kerning. That code path should be pretty well 
> optimised in Qt already (if we're not hitting opentype).

I have by no near the knowledge about Qt text rendering as you and Simon
have... Some month ago I was experimenting with text rendering to not
go through the MultiEngine QFontEngine... rendering was broken but I think
I saw a small speed up too. Ofcourse this is not as significant as other parts
of our stack.


> I think we should try to start by fixing the networking stack. Other options I 
> was wondering about is whether we can move image decoding into a thread as 
> well, so that we don't block our main parser.

I'm happy Markus is working on the networking side and for the image
decoding... I heard that Symbian had asynchronous image decoders and we
might be able to do the same again. The other question is what would you
like to see used. The webcore image decoders or the Qt ones?

holger