Closed Bug 1637067 Opened 10 months ago Closed 10 months ago

Blurred SVG - Background-image regression after 75.0b9


(Core :: Graphics: WebRender, defect)

77 Branch



Tracking Status
firefox-esr68 --- unaffected
firefox76 --- wontfix
firefox77 --- wontfix
firefox78 --- fixed


(Reporter: imagoiq, Assigned: tnikkel)


(Regression, )


(Keywords: regression)


(7 files, 1 obsolete file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0

Steps to reproduce:

The P letter is blurred on the right. This issue only happen since version 76.0 (last working version is 75.0b9)

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → SVG
Product: Firefox → Core

Looks fine to me but I'm on a Mac. Perhaps you could find a regression range by using

Flags: needinfo?(imagoiq)

Because this bug's Severity is normal and has not been changed, and this bug's priority is -- (none,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Severity: normal → --
Flags: needinfo?(imagoiq)

I've run the tool, it crash after "autoland build: c030dc56" (I've tried 3 times and filled a bug: But in the end, it seems that the bisection is done. Seems related to:

Component: SVG → Graphics: WebRender
Ever confirmed: true
Attachment #9147533 - Attachment is obsolete: true
Flags: needinfo?(tnikkel)
Has Regression Range: --- → yes
Has STR: --- → yes
OS: Unspecified → All
Hardware: Unspecified → All
Assignee: nobody → tnikkel
Flags: needinfo?(tnikkel)
Attached file reduced testcase

This is a reduced testcase.

Actually, this testcase shows a bug existed even before bug 1626259. This testcase is blurry even before bug 1626259 (whereas the original testcase looked pretty crisp before bug 1626259). It gets even more blurry after bug 1626259.

I should be able to make this testcase crisp, thus fixing the recent regression and fixing the pre-existing bug (it seemed to exist for quite a while before).

transform_style is set to frame->Extend3DContext, but ChooseScale uses frame->Combines3DTransformWithAncestors()

In StackingContextHelper::StackingContextHelper we want to handle the case of "no passed in transform" differently from "passed in transform but it cannot be drawn 2d". This is a little tricky because ChooseScale always has a transform passed in: in the non-wr case it is a scaling matrix by the parent scale. We could call ChooseScale if canDraw2D is false and get the same value for mScale but we also need to keep mInheritedTransform in sync.

This issue arose before:

And we want to be careful not to regress that bug, that bug was concerning content without a transform, so we should be good.

The testcase has a parent element with rotateY(-80deg) and a child element with rotateY(80deg), the combined transform is flat with no scaling even though each transform individually would have a very small x scale. There's no way to choose a good scale by looking at each transform individually, and since we only currently store transforms as 2d matrices we can't look at the full combined transform in order to choose a scale. Thus we must use a unit scale, like ChooseScale does.

Depends on D75288

The existing test compares a 3d scene to a "hand drawn" version of the scene using 2d primitives and was never expected to match perfectly, but instead just provide something to compare against better than saying it's not a blank page.

The new test looks visually identical, the fuzz is around the edges of the text.

Depends on D75289

Pushed by
Use the same kind of preserve3d in the StackingContextHelper constructor as in ChooseScale. r=jrmuizel
Make the StackingContextHelper constructor handle transforms that cannot be drawn 2d the same as ChooseScale. r=jrmuizel
Add reftest, adjust fuzz expectations of existing test. r=jrmuizel
Pushed by
Further adjust fuzz on preserve3d-scale.html for android hardware reftests.
You need to log in before you can comment on or make changes to this bug.