Closed
Bug 1059493
Opened 10 years ago
Closed 10 years ago
[CSS/SVG Filters][Regression] Previous filter rendering isn't cleared when filtered element is moved using margin property
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 1021564
People
(Reporter: mvujovic, Unassigned)
Details
Attachments
(1 file)
(deleted),
text/html
|
Details |
In the reproduction, press the "Move" button, which moves the filtered (hue-rotated) element right. In today's Nightly, the previous rendering of the filtered element remains, but it shouldn't.
This behavior occurs for both SVG and CSS filters.
This is a regression. I narrowed down the regression date using Nightlies:
Last good Nightly (May 13, 2014):
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/05/2014-05-13-mozilla-central-debug/
First bad Nightly (May 14, 2014):
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/05/2014-05-14-mozilla-central-debug/
I'm still looking for the change that caused it. I noticed Bug 1008301 talks about invalidation and was landed on May 13.
I thought I might've broke something in Bug 948265, but I didn't land anything in May, so I don't think so. I also debugged this a bit, comparing today's code with code from April, and it looks like the invalid area values returned in FrameLayerBuilder::AddThebesDisplayItem [1] haven't changed much.
In the April build, I got invalid.GetBounds() == (0, 77, 200, 100) before the call to nsSVGIntegrationUtils::AdjustInvalidAreaForSVGEffects, and invalid.GetBounds() == (90, 77, 110, 100) after the call. In today's build, I get the same values (except 77 is 79, which shouldn't important).
AdjustInvalidAreaForSVGEffects calls down to nsFilterInstance::GetPostFilterDirtyArea, which eventually calls down to FilterSupport::ComputeResultChangeRegion. In FilterSupport::ComputeResultChangeRegion, we intersect the original invalid region with the filter region. This removes the original position of the filtered element from the invalid rect. I'm wondering if this is the problem. However, we did it before this regressed and we continue to do it now, so nothing has really changed there. But maybe changes from Bug 1008301 or another bug exposed this problem (if it is a problem).
Another note of interest- the bug doesn't occur when you move the element using 2D transforms.
[1]: http://dxr.mozilla.org/mozilla-central/source/layout/base/FrameLayerBuilder.cpp
Comment 1•10 years ago
|
||
This is exactly bug 1021564, which I'm trying to finish at the moment.
Reporter | ||
Comment 2•10 years ago
|
||
(In reply to Markus Stange [:mstange] from comment #1)
> This is exactly bug 1021564, which I'm trying to finish at the moment.
>
> *** This bug has been marked as a duplicate of bug 1021564 ***
Glad it's a dup! Thanks for working on the fix.
You need to log in
before you can comment on or make changes to this bug.
Description
•