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

RESOLVED FIXED in Firefox 67

Status

()

enhancement
P2
normal
RESOLVED FIXED
8 months ago
4 months ago

People

(Reporter: emilio, Assigned: kats)

Tracking

(Blocks 1 bug)

unspecified
mozilla67
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox67 fixed)

Details

()

Attachments

(4 attachments)

Consider the following test-case from bug 1224207:

https://bug1224207.bmoattachments.org/attachment.cgi?id=8829369

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

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
</div>
Reporter

Comment 2

8 months ago
https://drafts.fxtf.org/filter-effects/#FilterPrimitivesOverviewIntro 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?
Reporter

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.

https://treeherder.mozilla.org/#/jobs?repo=try&group_state=expanded&revision=403ce8ec555c8b711a1befa0a0448ce48ff9005c

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 kgupta@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/da356c59e50d
Turn the blur stddev value into a tuple with horizontal and vertical components. r=kvark
https://hg.mozilla.org/integration/autoland/rev/ffe37ad57ad7
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
bugherder
Status: NEW → RESOLVED
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.