Bug 39647 - Big rendering performance issue with multiple font-faces which cause recalculating styles
Summary: Big rendering performance issue with multiple font-faces which cause recalcul...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Dave Hyatt
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-24 23:19 PDT by michael lewis
Modified: 2010-08-26 12:34 PDT (History)
4 users (show)

See Also:


Attachments
Testcase with slow behaviour simulated with javascript (4.89 KB, text/html)
2010-05-24 23:19 PDT, michael lewis
no flags Details
Example of unreliable workaround to get styles to not recalculate several times. (5.08 KB, text/html)
2010-05-24 23:20 PDT, michael lewis
no flags Details
Patch (3.08 KB, patch)
2010-08-26 12:30 PDT, Dave Hyatt
simon.fraser: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description michael lewis 2010-05-24 23:19:01 PDT
Created attachment 56974 [details]
Testcase with slow behaviour simulated with javascript

At Scribd we've been @font-face excessively.  Unfortunately, getting multiple fonts to load quickly has proven to be quite the challenge.

I've narrowed it down to  to the fact that after each font-face loads, the style gets recalculated.  This even happens if you have several uri-encoded fonts in one CSS file.

The only way I've been able to get around this (sometimes) is displaying an element with a given font-face, setting its display to none  after a little bit, and then loading the CSS in.  This makes it (sometimes) load the font when the CSS is loaded without it having to recalculate the style.

This performance issue is most apparent when looking at the Timeline  view in developer tools and is most noticeable using chrome (it recalculates the layout a bit slower than Safari it seems).

The time to recalculate the style is much more significant on Scribds' website because there's toolbars, ads, and whatnot which give it more load I imagine.

I attached two files.  slowfont.html which is a repro of the performance issue.  fastfont.html is an example of the workaround (which works in chrome at least).  You'll notice in fastfont there are not N "Recalculate Style" events and it performs faster (even though it has 1.5 seconds worth of timeouts).

I haven't been able to figure out a reliable way to "prime" webkit to *quickly* load a font without it causing the layout to recalculate.
Comment 1 michael lewis 2010-05-24 23:20:19 PDT
Created attachment 56975 [details]
Example of unreliable workaround to get styles to not recalculate several times.
Comment 2 mitz 2010-05-25 15:13:19 PDT
See also bug 36303.
Comment 3 michael lewis 2010-05-25 15:16:37 PDT
Changing platform to all. (confirmed this happens in windows as well with at least with chrome).
Comment 4 michael lewis 2010-05-25 15:17:31 PDT
(In reply to comment #2)
> See also bug 36303.

We came across this as well.  This is why in the example I'm just setting the innerHTML to a big block of CSS.
Comment 5 Dave Hyatt 2010-08-26 12:30:38 PDT
Created attachment 65598 [details]
Patch
Comment 6 Dave Hyatt 2010-08-26 12:32:51 PDT
The attached patch will at least improve things when multiple fonts load synchronously at the same time.  However it doesn't address the more general concern that the entire document recalcs style when a font loads.  That's a pretty difficult problem to address without consuming a lot of memory (to point from the font back to the specific renderers that use it).
Comment 7 Dave Hyatt 2010-08-26 12:34:35 PDT
Fixed in r66122.  Please open a new bug if your particular use case is still slow.