Bug 233684 – [Performance test] Add test lots-of-self-painting-layers.html

• Component: Layout and Rendering
• Status: RESOLVED FIXED

[cathiechen]

Add a test to track the repaint performance of self-painting layers.

[cathiechen]

Created attachment 445527 [details]
Patch

[cathiechen]

The performance regression caused by self-painting layer.

Self-paint layers(position: relative):
:Time -> [515.0000000000018, 452, 452, 450, 453, 660, 657, 655.0000000000018, 656.0000000000018, 652, 673.9999999999982, 657.0000000000018, 661, 656, 661, 659, 660.9999999999964, 663.9999999999964, 659, 675] ms
    mean: 611.4499999999998 ms
    median: 657.0000000000009 ms
    stdev: 88.24038638556408 ms
    min: 450 ms
    max: 675 ms

Normal flow layers(position: static):
:Time -> [471, 342, 343, 335, 335, 402, 396, 383, 390, 385, 390, 387, 382, 381, 384, 379, 381.0000000000018, 385.0000000000018, 381, 381] ms
    mean: 380.6500000000002 ms
    median: 382.5 ms
    stdev: 29.207560304608954 ms
    min: 335 ms
    max: 471 ms

[Radar WebKit Bug Importer]

<rdar://problem/86193972>

[Nikolas Zimmermann]

I wouldn't call it a performance regression, after all it's a different mode. Creating N layers each rendering M elements vs. rendering one layer that renders N*M elements is naturally different: there's non-negligible amount of overhead associated with the management of layers, such as updateLayerPosition(s), etc.

Or do you call it a regression, since it was better at some point?

[cathiechen]

(In reply to Nikolas Zimmermann from comment #4)
> I wouldn't call it a performance regression, after all it's a different
> mode. Creating N layers each rendering M elements vs. rendering one layer
> that renders N*M elements is naturally different: there's non-negligible
> amount of overhead associated with the management of layers, such as
> updateLayerPosition(s), etc.
> 

Yeah, I agree with you, they are different modes.

I called this as a regression, because we were addressing a performance regression for CSS contain. Like position: relative, CSS contain creates self-painting layers, the overhead of self-painting layers caused the regression.
Because the regression is not specific to CSS contain, and CSS contain is not enabled at that time. So we created this test, and keep calling it as a regression.

I guess we can call this test as a tracking for the overhead cost of self-painting layers. What do you think?


> Or do you call it a regression, since it was better at some point?

Nope.

[Nikolas Zimmermann]

(In reply to cathiechen from comment #5)
> (In reply to Nikolas Zimmermann from comment #4)
> > I wouldn't call it a performance regression, after all it's a different
> > mode. Creating N layers each rendering M elements vs. rendering one layer
> > that renders N*M elements is naturally different: there's non-negligible
> > amount of overhead associated with the management of layers, such as
> > updateLayerPosition(s), etc.
> > 
> 
> Yeah, I agree with you, they are different modes.
> 
> I called this as a regression, because we were addressing a performance
> regression for CSS contain. Like position: relative, CSS contain creates
> self-painting layers, the overhead of self-painting layers caused the
> regression.
> Because the regression is not specific to CSS contain, and CSS contain is
> not enabled at that time. So we created this test, and keep calling it as a
> regression.
> 
> I guess we can call this test as a tracking for the overhead cost of
> self-painting layers. What do you think?
Agreed, I just found the wording regression confusing and thought you were really fixing a regression from a certain revision, that's not the case, so everything is fine.

Thanks, for looking at layer performance, very important for LBSE to migitate the self-painting layer overheads as much as possible.

[cathiechen]

Created attachment 447008 [details]
Patch

[cathiechen]

(In reply to Nikolas Zimmermann from comment #6)
> (In reply to cathiechen from comment #5)
> > (In reply to Nikolas Zimmermann from comment #4)
> > > I wouldn't call it a performance regression, after all it's a different
> > > mode. Creating N layers each rendering M elements vs. rendering one layer
> > > that renders N*M elements is naturally different: there's non-negligible
> > > amount of overhead associated with the management of layers, such as
> > > updateLayerPosition(s), etc.
> > > 
> > 
> > Yeah, I agree with you, they are different modes.
> > 
> > I called this as a regression, because we were addressing a performance
> > regression for CSS contain. Like position: relative, CSS contain creates
> > self-painting layers, the overhead of self-painting layers caused the
> > regression.
> > Because the regression is not specific to CSS contain, and CSS contain is
> > not enabled at that time. So we created this test, and keep calling it as a
> > regression.
> > 
> > I guess we can call this test as a tracking for the overhead cost of
> > self-painting layers. What do you think?
> Agreed, I just found the wording regression confusing and thought you were
> really fixing a regression from a certain revision, that's not the case, so
> everything is fine.
> 
> Thanks, for looking at layer performance, very important for LBSE to
> migitate the self-painting layer overheads as much as possible.

Great! Thanks for pointing this out:)

[EWS]

Committed r286954 (245179@main): <https://commits.webkit.org/245179@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 447008 [details].