The order in which blurs and scales are applied in WR seems different to Gecko and other browsers.

RESOLVED FIXED in Firefox 67



8 months ago
4 months ago


(Reporter: emilio, Assigned: kats)


(Blocks 1 bug)

Dependency tree / graph

Firefox Tracking Flags

(firefox67 fixed)




(4 attachments)

Consider the following test-case from bug 1224207:

In WR the text looks way less blurry, presumably because we scale, then blur, instead of blurring, then scaling.

Comment 1

8 months ago
I would've expected WR to generate the same output as other browsers if I wrap it in a scaling transform, but no such luck:

<div style="transform: scale(5); transform-origin: 0 0;">
  <p style="filter: blur(1px);">hello

Comment 2

8 months ago says:

> To provide high quality rendering, all filter primitives should operate in a device dependent coordinate space, the operating coordinate space, taking device pixel density, user space transformations and zooming into account. To provide a platform independent alignment, attribute and property values are often relative to a coordinate system described by the primitiveUnits attribute. User agents must scale these relative attributes and properties to the operating coordinate space.

I think that means that the blur of a filter needs to account for the inherited transform scale... But I'm not sure what that means when the scale is not 1d...
What does gecko do under a mixed-dimension scale?

Comment 4

8 months ago
(In reply to Alexis Beingessner [:Gankro] from comment #3)
> What does gecko do under a mixed-dimension scale?

Gecko first applies filters then transforms, I think that matches the spec and all browsers except WR.
Priority: -- → P4

Kats, are you interested in looking at this?

Assignee: nobody → kats
Flags: needinfo?(kats)

Sure, as long as it doesn't need to be done in a hurry. It will take me some time to find and understand the relevant code paths.

Flags: needinfo?(kats)
Posted file testcase
Attachment #9043125 - Attachment mime type: text/plain → text/html

From looking at the source I suspect the blur code just isn't taking into account any scale at all between the blur and the nearest rasterization root. And the mixed-dimension scale is relevant because we'll need to store the blur for each dimension separately to handle that scenario.

Attachment #9044206 - Attachment mime type: text/plain → text/html

A patch like this one solves the issue here, but I'm having a hard time writing reftests for this. Also my reftest attempts thus far seem to expose other bugs. sigh

There was just one other actual bug, for which I filed bug 1529992. And I managed to write yaml reftests for this bug, so that's all good now.

See Also: → 1529992

Without this patch any enclosing scale transform between a blurred
picture and the nearest raster root was being ignored entirely for the
purposes of blur.

Also includes a couple of reftests to exercise this code.

Depends on D20907

Comment 15

4 months ago
Pushed by
Turn the blur stddev value into a tuple with horizontal and vertical components. r=kvark
Multiply transform scales into the blur radius for blur filters. r=kvark
Blocks: wr-67
No longer blocks: stage-wr-trains
Priority: P4 → P2

Comment 16

4 months ago
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
You need to log in before you can comment on or make changes to this bug.