Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upAutogenerate compute_damage #20001
Autogenerate compute_damage #20001
Conversation
highfive
commented
Feb 9, 2018
|
Heads up! This PR modifies the following files:
|
highfive
commented
Feb 9, 2018
|
r? @mbrubeck |
|
There were a bunch of properties that in the old code went unmentioned and are now "repaint". Should they all fall under the repaint category?
|
| [ServoRestyleDamage::REPAINT, ServoRestyleDamage::REPOSITION, | ||
| ServoRestyleDamage::STORE_OVERFLOW, ServoRestyleDamage::BUBBLE_ISIZES, | ||
| ServoRestyleDamage::REFLOW_OUT_OF_FLOW, ServoRestyleDamage::REFLOW]) || | ||
| restyle_damage_reflow!(old, new, damage, |
This comment has been minimized.
This comment has been minimized.
mbrubeck
Feb 9, 2018
Contributor
On second thought, this should be named reflow_out_of_flow instead of just reflow, because it doesn't include REFLOW damage.
reflow_and_bubble could be renamed to just reflow.
I believe these can stay "repaint".
We access these during flow construction so they should be
These should be
I believe these can be
I'm not sure about whether we need to set damage for these, or if the animation code will take care of triggering appropriate damage and relayouts when the actual style changes get applied... |
|
Done. |
|
@bors-servo try Wonder if this causes new passes. |
Autogenerate compute_damage fixes #10622 <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/20001) <!-- Reviewable:end -->
|
|
|
Tests for these are tricky. Setting "too much" damage doesn't cause any bugs, just suboptimal performance. Setting "too little" damage causes bugs only in incremental layout, which don't affect reftests unless they are very specifically written to trigger them. |
|
So there's something here that concerns me, which is that you really really want to not make each property change to imply a particular restyle damage, at least eventually. See https://searchfox.org/mozilla-central/rev/a5abf843f8fac8530aa5de6fb40e16547bb4a47a/layout/style/nsStyleContext.cpp#349, for example, and there are more specific examples in the calcdifference methods of style structs. This may be fine for now I guess. May I suggest |
|
Also, I've been thinking on splitting Gecko's model to be different. In particular, the style system will only know whether inherited / reset / variables changed. Then each particular frame / flow type will diff and apply the damage properly. This is handy because changing properties, for example, in column code, may not / will not really affect non-multicol flows, and thus any flow type but multicol may as well skip them. Also, there's another optimization that you really really want but you don't have right now, which is skipping the deep comparison iff the structs are pointer-equal (which is somewhat common). |
Yeah, let's land this for now. It's an improvement for correctness and has the same performance as our old servo code, even if future optimizations might need a different approach.
That sounds good. r=mbrubeck with that change and test-tidy fixes. |
064739c
to
4250233
|
@bors-servo r=mbrubeck try- |
|
|
Autogenerate compute_damage fixes #10622 <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/20001) <!-- Reviewable:end -->
|
|
Manishearth commentedFeb 9, 2018
•
edited by SimonSapin
fixes #10622
This change is