308
edits
Servo/StyleUpdateOnDOMChange: Difference between revisions
→Options for Servo
| Line 56: | Line 56: | ||
One thing that Servo will have that neither WebKit nor Gecko does is the ability to consider both the pre-change and post-change states of the DOM, if we're willing to do such processing as part of the "discard the old read pointers" process. This can allow us to completely or partially defer processing of whether restyles are needed from when changes are actually made to the discarding process. Unfortunately, what that will require is running said deferred processing on the DOM thread, since that's the only place we can safely access both the old and new DOM states. We may want to restrict this to only particular things where the win from having access to both the old and new value is particularly meaningful (e.g. class attribute changes)? | One thing that Servo will have that neither WebKit nor Gecko does is the ability to consider both the pre-change and post-change states of the DOM, if we're willing to do such processing as part of the "discard the old read pointers" process. This can allow us to completely or partially defer processing of whether restyles are needed from when changes are actually made to the discarding process. Unfortunately, what that will require is running said deferred processing on the DOM thread, since that's the only place we can safely access both the old and new DOM states. We may want to restrict this to only particular things where the win from having access to both the old and new value is particularly meaningful (e.g. class attribute changes)? | ||
It seems to me that we can mix and match the Gecko and WebKit approaches here as needed, depending on how fast we can make style recomputation. | |||
The one thing I want to avoid that Gecko does right now is interrogating a whole bunch of objects to find out whether a change is style-relevant. We should propagate all that information back to a single object. This change could even be made in Gecko today.... | |||