Closed Bug 1499113 Opened 2 years ago Closed 2 years ago

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


(Core :: Graphics: WebRender, enhancement, P2)




Tracking Status
firefox67 --- fixed


(Reporter: emilio, Assigned: kats)





(4 files)

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.
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> 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?
(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)
Attached 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

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
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
See Also: → 1561775
You need to log in before you can comment on or make changes to this bug.