When an SVG filter is used inside content that is scaled using a CSS transform, the position of the filter output is sometimes incorrect. In the attached test case there is a filter applied to a shape. The shape is then reproduced with just a stroke. The stroke should sit on top of the blurred shape. If you look at the SVG file alone, or set the scale to 1, the result is as expected. With the scale set to 1.2 the two shapes fail to align. Interestingly the horizontal position seems fine.

Hmm. I'm not seeing this problem, either in current m-c, or if F13.

(In reply to Jonathan Watt [:jwatt] from comment #1) > Hmm. I'm not seeing this problem, either in current m-c, or if F13. I see it in trunk and Aurora. Might be Windows specific. What platform are you on?

Mac. What if you turn on/off hardware acceleration, or any other gfx stuff that might affect this?

CC'ing roc, since he may be the only person with a Window's machine who knows the CSS-transforms code well enough to track this down.

(In reply to Jonathan Watt [:jwatt] from comment #3) > Mac. What if you turn on/off hardware acceleration, or any other gfx stuff > that might affect this? Yeah, if I set gfx.direct2d.disabled to true it renders correctly.

Can you check the layer state too please (in about:support)

(In reply to Matt Woodrow (:mattwoodrow) from comment #6) > Can you check the layer state too please (in about:support) I get: GPU Accelerated Windows: 1/1 Direct3D 10

Oh, and AzureBackend: direct2d

Bas, see comment 5.

Most likely an Azure-drawn content bug.

I'm not sure if this is related, but I'm also seeing incorrect results with non-scaling stroke when direct2d is enabled for the following test: http://schepers.cc/svg/vectoreffects/nonscalingstroke.svg Specifically, the stroke appears way off to the left (i.e. doesn't even line up with the fill). It's fine with direct2d disabled.

This appears to be affected by regular SVG transforms too. I'm seeing it, or something very similar, in situations where animateTransform is applied.

There should probably be a reftest for this too. Will add tomorrow.

Regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=36e938e51481&tochange=f43e8d300f21 Which points to: Bug 715768: Enable Azure-Thebes wrapper by default for D2D

Comment on attachment 643370 [details] [diff] [review] Reftest v1a Review of attachment 643370 [details] [diff] [review]: ----------------------------------------------------------------- I'm pretty sure you didn't mean to disable all those other test categories! Don't forget to re-enable before you push!

(In reply to Bas Schouten (:bas) from comment #17) > I'm pretty sure you didn't mean to disable all those other test categories! > Don't forget to re-enable before you push! Ooh yeah. Thanks for that!

Pushed to m-i: https://hg.mozilla.org/integration/mozilla-inbound/rev/9f9d8eb30fb7 https://hg.mozilla.org/integration/mozilla-inbound/rev/5510df5fbe30

https://hg.mozilla.org/mozilla-central/rev/9f9d8eb30fb7 https://hg.mozilla.org/mozilla-central/rev/5510df5fbe30

Comment on attachment 643150 [details] [diff] [review] Proposed patch v1a Requesting approval to land on Aurora and Beta [Approval Request Comment] Bug caused by (feature/regressing bug #): 715768 User impact if declined: Filter effects in some cases render in the wrong location Testing completed (on m-c, etc.): Baked on m-c Risk to taking this patch (and alternatives if risky): None String or UUID changes made by this patch: None

Comment on attachment 643150 [details] [diff] [review] Proposed patch v1a Go ahead and land to branches, no risk and baked on m-c looks good.

Pushed to beta and aurora: https://hg.mozilla.org/releases/mozilla-beta/rev/7ad53adfa8c1 https://hg.mozilla.org/releases/mozilla-aurora/rev/f62ab8356d23

Verified fixed on FF 15b3 loading the test case in comment 0. Able to see the issue on FF 15b2.