If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

[CSS/SVG Filters][Regression] Previous filter rendering isn't cleared when filtered element is moved using margin property

RESOLVED DUPLICATE of bug 1021564

Status

()

Core
Graphics
RESOLVED DUPLICATE of bug 1021564
3 years ago
3 years ago

People

(Reporter: Max Vujovic, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
Created attachment 8480120 [details]
Reproduction

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
(Reporter)

Updated

3 years ago
Blocks: 869828
This is exactly bug 1021564, which I'm trying to finish at the moment.
No longer blocks: 869828
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1021564
(Reporter)

Comment 2

3 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.