Last Comment Bug 765107 - Filter output is mislocated with CSS transforms
: Filter output is mislocated with CSS transforms
Status: RESOLVED FIXED
: regression
Product: Core
Classification: Components
Component: SVG (show other bugs)
: Trunk
: x86_64 Windows 7
: -- normal (vote)
: mozilla17
Assigned To: Brian Birtles (:birtles)
:
Mentors:
Depends on:
Blocks: 715768
  Show dependency treegraph
 
Reported: 2012-06-14 18:01 PDT by Brian Birtles (:birtles)
Modified: 2012-08-02 04:50 PDT (History)
8 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
unaffected
verified
fixed


Attachments
Test case (825 bytes, text/html)
2012-06-14 18:01 PDT, Brian Birtles (:birtles)
no flags Details
Proposed patch v1a (1.07 KB, patch)
2012-07-17 14:55 PDT, Brian Birtles (:birtles)
bas: review+
lukasblakk+bugs: approval‑mozilla‑aurora+
lukasblakk+bugs: approval‑mozilla‑beta+
Details | Diff | Splinter Review
Reftest v1a (3.92 KB, patch)
2012-07-18 07:40 PDT, Brian Birtles (:birtles)
bas: review+
Details | Diff | Splinter Review

Description Brian Birtles (:birtles) 2012-06-14 18:01:35 PDT
Created attachment 633342 [details]
Test case

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.
Comment 1 Jonathan Watt [:jwatt] (catching up after vacation) 2012-06-16 10:00:59 PDT
Hmm. I'm not seeing this problem, either in current m-c, or if F13.
Comment 2 Brian Birtles (:birtles) 2012-06-17 15:51:14 PDT
(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?
Comment 3 Jonathan Watt [:jwatt] (catching up after vacation) 2012-06-19 12:39:08 PDT
Mac. What if you turn on/off hardware acceleration, or any other gfx stuff that might affect this?
Comment 4 Jonathan Watt [:jwatt] (catching up after vacation) 2012-06-19 15:52:50 PDT
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.
Comment 5 Brian Birtles (:birtles) 2012-06-19 16:26:14 PDT
(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.
Comment 6 Matt Woodrow (:mattwoodrow) 2012-06-19 16:35:24 PDT
Can you check the layer state too please (in about:support)
Comment 7 Brian Birtles (:birtles) 2012-06-19 16:47:14 PDT
(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
Comment 8 Brian Birtles (:birtles) 2012-06-19 16:48:41 PDT
Oh, and AzureBackend: direct2d
Comment 9 Jonathan Watt [:jwatt] (catching up after vacation) 2012-06-20 14:47:04 PDT
Bas, see comment 5.
Comment 10 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2012-06-20 21:08:51 PDT
Most likely an Azure-drawn content bug.
Comment 11 Brian Birtles (:birtles) 2012-06-25 16:10:07 PDT
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.
Comment 12 Brian Birtles (:birtles) 2012-07-05 00:56:53 PDT
This appears to be affected by regular SVG transforms too. I'm seeing it, or something very similar, in situations where animateTransform is applied.
Comment 13 Brian Birtles (:birtles) 2012-07-17 14:55:24 PDT
Created attachment 643150 [details] [diff] [review]
Proposed patch v1a
Comment 14 Brian Birtles (:birtles) 2012-07-17 15:00:07 PDT
There should probably be a reftest for this too. Will add tomorrow.
Comment 15 Brian Birtles (:birtles) 2012-07-18 07:40:11 PDT
Created attachment 643370 [details] [diff] [review]
Reftest v1a
Comment 16 Brian Birtles (:birtles) 2012-07-18 08:10:28 PDT
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 17 Bas Schouten (:bas.schouten) 2012-07-18 08:16:57 PDT
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!
Comment 18 Brian Birtles (:birtles) 2012-07-18 08:33:36 PDT
(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!
Comment 21 Brian Birtles (:birtles) 2012-07-20 11:13:12 PDT
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 22 Lukas Blakk [:lsblakk] use ?needinfo 2012-07-20 15:11:27 PDT
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.
Comment 24 Paul Silaghi, QA [:pauly] 2012-08-02 04:50:35 PDT
Verified fixed on FF 15b3 loading the test case in comment 0. Able to see the issue on FF 15b2.

Note You need to log in before you can comment on or make changes to this bug.