| Summary: | Big rendering performance issue with multiple font-faces which cause recalculating styles | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | michael lewis <mikelikespie> | ||||||||
| Component: | Layout and Rendering | Assignee: | Dave Hyatt <hyatt> | ||||||||
| Status: | RESOLVED FIXED | ||||||||||
| Severity: | Normal | CC: | ap, hyatt, jim, mitz | ||||||||
| Priority: | P2 | ||||||||||
| Version: | 528+ (Nightly build) | ||||||||||
| Hardware: | All | ||||||||||
| OS: | All | ||||||||||
| Attachments: |
|
||||||||||
Created attachment 56975 [details]
Example of unreliable workaround to get styles to not recalculate several times.
Changing platform to all. (confirmed this happens in windows as well with at least with chrome). (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. Created attachment 65598 [details]
Patch
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). |
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.