Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 11673bb9c2c0a3290320bd80bfd78ae3d16cc48e
https://github.com/WebKit/WebKit/commit/11673bb9c2c0a3290320bd80bfd78ae3d16cc48e
Author: Sammy Gill <[email protected]>
Date: 2026-06-03 (Wed, 03 Jun 2026)
Changed paths:
M Source/WebCore/rendering/style/RenderStyle+GettersInlines.h
M Source/WebCore/rendering/style/RenderStyle+SettersInlines.h
M Source/WebCore/rendering/style/RenderStyle.h
M Source/WebCore/style/StyleDifference.cpp
M Source/WebCore/style/StyleResolveForDocument.cpp
M Source/WebCore/style/computed/StyleComputedStyleBase+GettersInlines.h
M Source/WebCore/style/computed/StyleComputedStyleBase+SettersInlines.h
M Source/WebCore/style/computed/StyleComputedStyleBase.h
M Source/WebCore/style/computed/data/StyleInheritedRareData.cpp
M Source/WebCore/style/computed/data/StyleInheritedRareData.h
Log Message:
-----------
[EvaluationTimeZoom] Add way to access device scale factor cheaply during
layout.
https://bugs.webkit.org/show_bug.cgi?id=316009
rdar://problem/178439138
Reviewed by Simon Fraser and Vitor Roriz.
It seems like in order to properly mark StyleLineWidth as an “Unzoomed" type,
we will need access to the device scale factor since we will need it for pixel
snapping. Currently, the only way to access it during layout, which is where
most of the evaluation occurs, is to get it off of the Page since that is
where it lives. This requires jumping through quite a few pointers since we need
to go from the renderer and through its Node, Document, and finally get to the
Page. Unfortunately, A/B testing shows that this results in quite a significant
Speedometer regression. Some investigation uncovered that the reason for this
is due to these device scale factor accesses and not other factors, such as
the extra work that comes from the pixel snapping logic.
The goal of this patch is to introduce a new way to access the device scale
factor during layout without suffering from performance regressions. After
experimenting with a few different approaches, it seems like the best option
will be to have it live on InheritedRareData. There was a point in time where
we were already doing this, but I ended up removing it in a previous commit
(308616@main) as a cleanup patch since it was unused at the time.
A/B testing with this patch and one that marked StyleLineWidth as Unzoomed was
neutral on both Speedometer and MotionMark.
Here are a few other ideas that I had but did not perform as well as the above
with
respect to perf:
1.) Adding a fast path static function that could be used. The idea was that
we could keep a synchronized device scale factor on Page that would exist and
be returned if the value was the same across all the pages and otherwise use
a passed in callback if it did not. This was a Speedometer regression across
the board on different devices and subtests.
2.) Storing the value on NonInheritedMiscData. This could arguably make more
sense than the current location on InheritedRareData, but this results in
quite a severe regression on certain devices. Specifically, on devices where
The device scale factor does not match the initial value. We do a lot more work
to get this value updated across all the Style objects.
3.) Directly on the Style object itself. This also resulted in a Speedometer
regression, but I did not investigate super deeply into the cause of it. I
presume it comes from changing memory/caching characteristics since we are
increasing the style of the object.
Canonical link: https://commits.webkit.org/314472@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
