Layout batching #259
Layout batching #259
Conversation
Neither webfont.FontWatchRunner.fontRulerC_ nor webfont.FontWatchRunner.LastResortFonts.MONOSPACE doesn't seem to be used. Let's remove it.
Changing the ruler's font while computing the width forces browsers to run the layout computation multiple times, which is sometimes expensive. This change gives each last resort font its own ruler, eliminates the font changes in start(). This allows browsers to compute the layout less often, save the overhead surrounding the layout routine.
|
@bramstein Would you mind taking a look at this as well? This is for browsers without native font loading API. The speedup is not that big, but still worth having IMO. |
|
These look like good changes. On which browsers have you seen the speedup? So what we're changing now is replacing modifying an existing DOM element with inserting more DOM elements? |
|
Yes, it adds extra DOM node to get rid of updating the style of existing node. By doing this, we can follow "create DOM once, then layout it at once" pattern which reduces the number of layout invocations. I'm using Chrome for Android and Chromium based WebView on Android. Also, the product I'm working on has to use much longer test string as it sometimes uses non-latin fonts. That's a big reason why the layout time matters. |
|
Excellent, I'll merge this in and do a release. Thanks a lot! |
|
Thanks a lot! And let me be annoying here - What about #260 ? |
ghost
mentioned this pull request
This change speeds up the loading time in some scenarios where
The app we're developing sees 10% speedup for the font loading time with this change.