Bugzilla

On pages with many scrollable elements, we can end up spending a lot of time styling the anonymous scrollbar content on the main thread.  For example, when loading the single page HTML spec, we spend ~840 ms out of the total ~8,950 ms load time (~9%) under `nsCSSFrameConstructor::GetAnonymousContent`'s call to `StyleNewSubtree`.

This is what the distribution of frame types for `GetAnonymousContent` calls looks like in that document:

```
      1 GetAnonymousContent Canvas
    739 GetAnonymousContent GfxButtonControl
    912 GetAnonymousContent Details
   1229 GetAnonymousContent Scroll
   2234 GetAnonymousContent Scrollbar
```

So 66% of the anonymous content generating frames are scrollbar-related.  Scrollframes generate four elements (two `<scrollbar>`s, a `<scrollcorner>, and a `<resizer>`).  Scrollbars themselves generate six elements (four `<scrollbarbutton>`s, some of which are display:none depending on the platform, the `<slider>`, and the `<thumb>`).  So by number of elements these consist of the vast majority of anonymous content styling work.

If we ignore scrollbar-color, then the number of unique `ComputedStyle` objects we need for all the scrollbar parts is manageable, and mostly depends on a few specific attributes set on the elements.  I think the only other inherited property values that matter for scrollbar parts are scrollbar-width and visibility.  Apart from that, we should be able to cache the `ComputedStyle` for a given combination of these attributes and reuse them on subsequent scrollable elements.

The downside of this is increased coupling between the UA sheets that style the scrollbar parts and the code that checks the attributes that we'd key the cache off.  But the UA sheet rules for scrollbar parts don't change very often, so maybe a comment reminding people to check whether the caching code needs updating is enough.

On pages with many scrollable elements, we can end up spending a lot of time styling the anonymous scrollbar content on the main thread.  For example, when loading the single page HTML spec, we spend ~840 ms out of the total ~8,950 ms load time (~9%) under `nsCSSFrameConstructor::GetAnonymousContent`'s call to `StyleNewSubtree`.

This is what the distribution of frame types for `GetAnonymousContent` calls looks like in that document:

```
      1 GetAnonymousContent Canvas
    739 GetAnonymousContent GfxButtonControl
    912 GetAnonymousContent Details
   1229 GetAnonymousContent Scroll
   2234 GetAnonymousContent Scrollbar
```

So 66% of the anonymous content generating frames are scrollbar-related.  Scrollframes generate four elements (two `<scrollbar>`s, a `<scrollcorner>`, and a `<resizer>`).  Scrollbars themselves generate six elements (four `<scrollbarbutton>`s, some of which are display:none depending on the platform, the `<slider>`, and the `<thumb>`).  So by number of elements these consist of the vast majority of anonymous content styling work.

If we ignore scrollbar-color, then the number of unique `ComputedStyle` objects we need for all the scrollbar parts is manageable, and mostly depends on a few specific attributes set on the elements.  I think the only other inherited property values that matter for scrollbar parts are scrollbar-width and visibility.  Apart from that, we should be able to cache the `ComputedStyle` for a given combination of these attributes and reuse them on subsequent scrollable elements.

The downside of this is increased coupling between the UA sheets that style the scrollbar parts and the code that checks the attributes that we'd key the cache off.  But the UA sheet rules for scrollbar parts don't change very often, so maybe a comment reminding people to check whether the caching code needs updating is enough.