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 upAdd support for color animated properties #2149
Conversation
0112536
to
2539749
|
backtrace of the assertion mentioned in the PR description:
|
|
Wow, this is amazing work. Apologies I haven't gotten to it yet - will run through this tomorrow. Not sure if relevant, but I think it's completely fine to do this incrementally (e.g. merge support for just animated color on rects, then follow up with other primitives etc), if that makes things easier. |
|
|
|
Reviewed 23 of 23 files at r1. webrender/examples/animation.rs, line 296 at r1 (raw file):
nit: extra spaces webrender/src/frame_builder.rs, line 844 at r1 (raw file):
If we were storing the value outside the property, then that would probably make this a lot simpler and remove the transmute nastiness you mentioned? webrender/src/prim_store.rs, line 1434 at r1 (raw file):
nit: extra spaces wrench/src/rawtest.rs, line 201 at r1 (raw file):
Perhaps we could instead have the interface be something like:
So that you can push a color directly in the common case? wrench/src/yaml_frame_writer.rs, line 739 at r1 (raw file):
Having to use all the mutability on stored items is why I originally had the resolved value stored outside the property binding. There's pros and cons to each. Comments from Reviewable |
|
This generally looks good to me! My main questions are whether (a) storing the resolved value outside the binding would remove a lot of the extra mutability here and also fix the transmute in the PR, and (b) if we should use the |
|
@glennw that I'm also going to revert my changes to add this animated color support to borders and save that for a follow up. |
|
I'm a little worried about the additional serialization/deserialization and display list size cost this might add. Should we measure it? |
|
@jrmuizel Yea, I'll do some measurements before merging anything. |
bf2707f
to
a82bb27
|
I've rebased this again and implemented the changes you suggested. The I also reverted my change to For now only rects, box shadows, and gradients have color animation support. Besides the assertion, another open question I have is about what good behavior for an initial value for color bindings would be. Should the client be expected to cc: @glennw |
| (None, true, true) | ||
| }, | ||
| PrimitiveKind::AlignedGradient | PrimitiveKind::AngleGradient | PrimitiveKind::RadialGradient => { | ||
| gpu_cache.invalidate(&metadata.gpu_location); |
This comment has been minimized.
This comment has been minimized.
| PrimitiveKind::Brush => { | ||
| let brush = &mut self.cpu_brushes[metadata.cpu_prim_index.0]; | ||
| if let BrushKind::Solid { ref mut color, ref binding } = brush.kind { | ||
| *color = scene_properties.resolve_color(&binding); |
This comment has been minimized.
This comment has been minimized.
nc4rrillo
Dec 5, 2017
Author
Contributor
Maybe I should add an if let &PropertyBinding::Binding(_) = binding here so I'm not trying to resolve PropertyBinding::Value properties?
|
Review status: 0 of 14 files reviewed at latest revision, 7 unresolved discussions. webrender/examples/animation.rs, line 296 at r1 (raw file): Previously, glennw (Glenn Watson) wrote…
Done. webrender/src/frame_builder.rs, line 844 at r1 (raw file): Previously, glennw (Glenn Watson) wrote…
Done. webrender/src/prim_store.rs, line 1434 at r1 (raw file): Previously, glennw (Glenn Watson) wrote…
Done. wrench/src/yaml_frame_writer.rs, line 739 at r1 (raw file): Previously, glennw (Glenn Watson) wrote…
Done. Reverted my change to PropertyBinding. wrench/src/rawtest.rs, line 201 at r1 (raw file): Previously, glennw (Glenn Watson) wrote…
Done. Comments from Reviewable |
|
Accidentally closed. Reopening. |
b76b8d8
to
b42f4ae
|
@glennw so I managed to also add support for borders (including complex ones) by moving the GPU block building out of the border code and into the primitive code. I did however run into the following issue while putting together the sample app where some of the borders are glitched: It only happens with Dashed/Dotted borders of a non zero radius. |
|
So the glitch above isn't related to my change, I'm trying to track down exactly what caused it but I'm pretty far back in the commit history and not having any luck so far. It seems to be affected by the allocation patterns of the render targets, as different changes (for example box shadow caching) have impacted where I see it show up. |
|
@nc4rrillo Interesting glitches! But if unrelated to this PR, it doesn't need to block this. Is this ready for re-review again, or is it still in progress? |
|
@glennw This is ready for review now. For default values, I hang it off of |
7d9980b
to
00920e9
|
|
|
|
|
Could you remove the merge commits and rebase it onto master instead? I'll run through this again today or tomorrow, and try to do some measurements of the DL deserialization time differences. I don't expect anything major, but I'll check just in case. |
|
Reviewed 4 of 23 files at r2, 5 of 15 files at r3, 5 of 8 files at r4, 6 of 6 files at r5. webrender/src/border.rs, line 111 at r5 (raw file):
I think we might need to leave doing borders to a follow up PR. In this code here, we determine how we are going to render the border during the scene construction. If the colors then change by an animation property, we would need to re-run this code to determine the most efficient path to render the border. webrender/src/box_shadow.rs, line 64 at r5 (raw file):
Same issue here, that we resolve during scene construction. If we remove the box shadow, and then it gets animated to a valid color, it won't appear. webrender/src/frame_builder.rs, line 764 at r5 (raw file):
Same issue here, unfortunately. We can't discard rectangles based on the scene properties, since they will then be removed if the initial resolved color is invalid. webrender/src/picture.rs, line 142 at r5 (raw file):
I don't quite follow why we need this code here? webrender/src/prim_store.rs, line 509 at r5 (raw file):
nit: extra spaces webrender/src/scene.rs, line 33 at r5 (raw file):
nit: extra spaces webrender/src/scene.rs, line 217 at r5 (raw file):
nit: extra spaces webrender/src/tiling.rs, line 808 at r5 (raw file):
Perhaps we should have a method to return the current value, to avoid duplication. Comments from Reviewable |
|
Ugh, I'm so sorry this has turned out to be way more complex than I thought it would. It hadn't occurred to me that we will need to change a lot of how we early reject primitives based on invalid color etc (which are what most of the substantive comments in the last review are in relation to). I'll be traveling most of next week - but I'll try to follow up on this again. I wonder if it's worth trying to land this with initial support for just the API changes and rectangles only (with the fixes to early discard of the primitives mentioned above)? That might let us get the initial support landed, and then work incrementally on each other primitive. Thoughts? |
|
PS: I removed the |
|
@glennw That sounds good to me. I'll rework this to support only rectangles for now. |
|
@nc4rrillo Thanks, and again, apologies for how tricky this has turned out to be. |
|
|
|
@nc4rrillo Should we close this for now? |
|
Yes I will reopen a PR once I have more time to work on this |


nc4rrillo commentedDec 1, 2017
•
edited
Fixes: #2118
Hi,
This is a patch to add support for animated color properties in WebRender.
Some things to note:
gpu_cache.invalidate()inprepare_prim_for_render.STR for the assertion is:
Things to do before merging:
gpu_cache.rsline 612This change is