WR SVG filters: Calculate proper get_rect/get_coverage and RenderTask target_size for filters
Categories
(Core :: Graphics: WebRender, task)
Tracking
()
People
(Reporter: ahale, Unassigned)
References
(Blocks 1 open bug)
Details
PictureCompositeMode::get_rect and get_coverage need to take into account the filter region provided by Gecko so that filters larger than the source primitive are not clipped to the source primitive rect, and filters smaller than the source primitive don't render the full rect where it is unnecessary.
How to do this properly has proven quite difficult to work out, studying Gecko FilterInstance code and take_context / wrap_prim_with_filters in WR hasn't led to a clear answer how to calculate this properly in my experiments, so in the interest of accelerating WR SVG filters we are using the original source primitive rect for now, but that means we currently can't accelerate some filter graphs because they produce a larger rect than the source primitives - fixing this would be a very good thing but not critical.
|
Reporter | |
Updated•6 months ago
|
|
|
Reporter | |
Comment 1•5 months ago
|
||
I have this partially worked out, enough for https://bugzilla.mozilla.org/show_bug.cgi?id=1824502 to be unblocked, but a real solution for no-primitives cases like feFlood on its own is elusive, we have to trust the subregions for that case, so they need to replace the bounds of the unclipped primitive clusters in the source picture for surface_rect to work in get_rect/get_coverage. I'm already computing an exact bounds for the filter padding (e.g. blur, feOffset, other area sampling effects like feMorphology, etc) so it will be easy once the clipped rect is based on the correct unclipped bounds to begin with.
|
|
Reporter | |
Comment 2•4 months ago
|
||
I've resolved this in my changes to the diff on Bug 1824502 so I am closing this bug preemptively.
Description
•