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

[Lars Knoll]

On Wednesday 16 December 2009 03:51:49 pm ext Antti Koivisto wrote:
> On Mon, Dec 14, 2009 at 9:51 AM, Lars Knoll
>  <lars.knoll at nokia.com<mailto:lars.knoll at nokia.com>> wrote:
> 
>> It seems most of these items are outside WebKit.
>> 
>> 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.
>> 
> I think we should definitely try this out. If we can substantially improve
>  latin text, that is a huge win for many users. Which languages actually
>  require shaping and kerning?
> 
> If we can make layouting go 10% faster I think it would be totally worth
>  it. Very few people are able to tell the difference in quality.

Not a lot of people can nail down why, but quite a few realize there is a 
difference in quality. But yes, it's something we should look into.

Looking back at Holger's initial mail, I now have a suspicion why font loading 
shows up quite a bit. It's a page about maxwell's equations, so it'll contain 
mathematical symbols. These can cause quite a bit of work in the font matching 
algorithms. Holger, how does the profile of a page with only latin text look 
like?

>> 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 think this should be tested too. WebKit has its own glyph cache for a
>  reason.

Yes, and Qt has fast paths there as well for a reason. I might be wrong, but 
the speed difference might not be huge. Glyph caching was very needed on ATSUI, 
where the conversion was slow, I'm not so sure how much we will gain on Qt.

>> 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.
>> 
> Image decoding should definitely be in a thread and preferably use hw when
>  possible.

Agreed.

Lars

> 
> 
>    antti
> 
> Cheers,
> Lars
> 
> > ideas greatly appreciated.
> >
> >        z
> >
> > _______________________________________________
> > webkit-qt mailing list
> > webkit-qt at lists.webkit.org<mailto:webkit-qt at lists.webkit.org>
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
> 
> _______________________________________________
> webkit-qt mailing list
> webkit-qt at lists.webkit.org<mailto:webkit-qt at lists.webkit.org>
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
>