Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[WIP] Redesigned clip and scroll API #3251
This is something I wanted for a long time: the spatial hierarchy that isn't mixed up with the clip hierarchy. The change dragged a bunch of other API fixes that were accumulated in our technical debt, so it grew rather big/scary.
The motivation is - removing the complexity of the API that we inherited from the past. Both Servo and Gecko are in a better position to explicitly tell us what the clip/spatial properties of items are, and they don't need to mix them up in the same type. The old API had more complex logic, more state, and caused the Gecko integration to be painful and non-solid (there are edge cases not handled properly).
It's great to finally see this change! I did a quick review of most of this patch and I'm happy to take a closer look later.
wrench/reftests/performance/no-clip-mask.png, line 0 at r3 (raw file):
I'm somewhat surprised that this patch causes a difference here. Do we know why?
Just one question above, since it's not clear to me that this should have affected any reftest outputs (and if that has any implications for Gecko / Servo).
Otherwise, it seems like we need:
Then this should be ready to merge.
@gw3583 I'm working on even more changes now that remove the clip-scroll stack completely from the API. More updates to come... and I'll double check the test. I assume there is a slight change in YAML reading semantics (e.g. parsing the "clip-and-scroll" field), since it diverges further from the actual WR API, and I'm trying to preserve compatibility with the existing reftests.
referenced this pull request
Nov 14, 2018
I've got to document this somewhere: we have a few places in DL building where the clip is literally smuggled through the scroll ID, while the clip ID is silently dropped:
What happens is
But the worst thing is that there is code in Gecko that relies on that behavior...