The stacking context tree rebuild had an optimization that skipped
rebuilding when a property changed between two values that both create
stacking contexts. This is correct for most properties (e.g. opacity
0.5 -> 0.8 doesn't change tree structure), but incorrect for z-index.
During tree construction, elements with z-index 0/auto are placed in
m_positioned_descendants_and_stacking_contexts_with_stack_level_0,
while elements with other z-index values are painted from m_children
(negative at step 3, positive at step 9 per CSS 2.1 Appendix E).
When z-index changed between non-auto values (e.g. 0 -> 10), the
optimization skipped the rebuild, leaving the element in the wrong
list and causing it to be painted from both step 8 and step 9.
This was visible on pages like shopify.com where elements with
transition-all would transition z-index, producing a flood of
"Painting commands are recorded twice for stacking context" messages.
Previously, any change to a property that affects stacking context would
trigger a full stacking context tree rebuild. However, an element only
creates or destroys a stacking context when a property crosses from its
"neutral" value to a "creating" value (or vice versa).
For example, animating `transform: translateX(10px)` to
`transform: translateX(20px)` previously triggered stacking context
rebuilds on every frame, but this is unnecessary because the stacking
context already exists.
Effects (opacity, blend mode, filters) must be applied in the parent's
coordinate space, before the element's transform. Previously this was
handled by manually switching to the parent's visual context when
applying effects at paint time.
By adding EffectsData to AccumulatedVisualContext and positioning it
before TransformData in the chain, effects are now naturally applied in
the correct order during display list replay, eliminating the special
case in StackingContext::paint().
For SVG filters that can generate content from empty elements (feFlood,
feImage, feTurbulence), a transparent FillRect command is emitted to
trigger the filter through the same AVC pipeline.
AccumulatedVisualContext nodes capture a snapshot of the current clip
rect when the tree is built, so we must invalidate whenever the clip
property changes.
AccumulatedVisualContext nodes capture a snapshot of the current
clip-path when the tree is built, so we must invalidate whenever the
clip-path changes.
Fixes regression introduced in 98afd82
Ensure AccumulatedVisualContext stays synchronized when CSS transform
properties change.
AccumulatedVisualContext copies transform and perspective matrices from
the paintable tree at assignment time. When CSS properties that affect
these matrices change (transform, rotate, scale, translate, perspective,
transform-origin, perspective-origin), we must rebuild the
AccumulatedVisualContext tree to reflect the new values.
This adds a rebuild_accumulated_visual_contexts flag to style
invalidation that triggers a full rebuild during the next paint.
Note: The current invalidation strategy is inefficient - it rebuilds
the entire tree even for single-element transform changes. This could
be improved by patching the AccumulatedVisualContext node in-place with
updated matrices, but only when the transform doesn't transition
from/to none (which would change the tree structure). This optimization
is left for future work.
This partially reverts commit 3aff3327c4
by removing the code change but keeping the added test.
Now that paintables visibility caching has been reverted, this is no
longer doing anything except causing excessive relayouts on pages
like https://linear.app/
As of 7dc8062 paintables compute and cache their visibility (which
depends on opacity) at construction - this cached value can fall out of
sync with reality if if the opacity changes to/from zero within the
lifetime of that paintable.
This commit invalidates layout when an opacity changes to/from zero so
that we reconstruct paintables with the correct visibility.
This reverts 0e3487b9ab.
Back when I made that change, I thought we could make our StyleValue
classes match the typed-om definitions directly. However, they have
different requirements. Typed-om types need to be mutable and GCed,
whereas StyleValues are immutable and ideally wouldn't require a JS VM.
While I was already making such a cataclysmic change, I've moved it into
the StyleValues directory, because it *not* being there has bothered me
for a long time. 😅
A change to a counter "definition" propagates to all subsequent
instances of this counter: descendents, siblings and their descendents
(the "next tree slice"). Rebuilding the layout tree (from the parent
node) covers at least the "next_tree_slice".
When position changes, we may need to make larger structural updates
to the layout tree. A simple relayout is not sufficient.
This was a source of flakiness in the engine, and gives us at least
+28 new WPT subtest passes.
Because we cache the transformed text string in text nodes affected by
text-transform, we have to actually update the layout tree when this
property value changes.
