Every complex DOM workloads should not hit a specific WebKit pathology

[rniwa]

The complex DOM content contains an overflow scroller (<div class="tree-area">) with many position:relative descendants (.spectrum-TreeView-itemIndicator), and the scroller is not a CSS stacking context. This triggers specific code paths related to async scrolling that we don't want affecting the performance on a whole set of subtests. While it's OK to have Speedometer test this code path on one subtest, other "complex DOM" subtests should be constructed in a way to exercise other code paths.

Specifying will-change: z-index on these overflow scroller will advert this pathology for example.

To put it another way, the request here is to vary complex DOM contents across the different subtests so as to avoid hitting the same pathology in every complex DOM workload.

[sulekhark]

The CSS property isolation:isolate (MDN doc) creates a CSS stacking context in a "pure" way without any other side effect. This might potentially be a general way to force the creation of a stacking context for an element. Perhaps, using this in a complex DOM variant would (unbiasedly) represent the many different scenarios in which a stacking context may be created.