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)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1021564

People

(Reporter: mvujovic, Unassigned)

Details

Attachments

(1 file)

Attached file Reproduction (deleted) —
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
Blocks: 869828
This is exactly bug 1021564, which I'm trying to finish at the moment.
No longer blocks: 869828
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
(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.

Attachment

General

Creator:
Created:
Updated:
Size: