1806281 - An image on a Codepen demo (https://codepen.io/Bupeldox/pen/eYRNYdJ) is blurry

Status: ASSIGNED

(Core :: Graphics: WebRender, defect)

Description

[Mayank Bansal]

Go to https://codepen.io/Bupeldox/pen/eYRNYdJ

Click on "begin the road trip"
A car image will appear

ER: crisp image
AR: Blurred image

Can repro on a build from 2020 with d3d11, so not a recent regression.

Comment 1

[Timothy Nikkel (:tnikkel)]

I see the same problem on Safari, but not on Chrome.

Comment 2

[Jonathan Kew [:jfkthame]]

The car image is actually a glyph from the emoji font. Disabling the animation that "bounces" the car up and down makes it become crisp in Firefox. It looks like the animation of the scale3d transform is causing us to switch to a different rendering codepath that is operating on a low-res bitmap rather than the higher-res version that we use if the rendering is not animated.

Comment 3

[Timothy Nikkel (:tnikkel)]

Interestingly, disabling the carIdle animation makes it crisp for me only on a retina screen, if the window is on my non-retina screen then it is still blurry.

Comment 4

[Timothy Nikkel (:tnikkel)]

It seems to be the perspective on the parent element that is the root of the problem. Our perspective handling in ChooseScale

https://searchfox.org/mozilla-central/rev/f40d29a11f2eb4685256b59934e637012ea6fb78/gfx/layers/wr/StackingContextHelper.cpp#46

doesn't seem to be quite right.

Comment 5

[Jonathan Kew [:jfkthame]]

Yes, ChooseScale() seems to just give up if perspective is involved and returns (1.0, 1.0). This means that we end up using a really small rendering of the car emoji (IIRC it's something like 12px), which then gets transformed as a bitmap image to the much larger size that actually appears.

As I understand it, there's not really any way for ChooseScale() to come up with a single "ideal" answer, because in the presence of perspective the final effective scale will vary across the image. However, falling back to (1.0, 1.0) means that any time the various transforms involved are going to substantially enlarge the image (prior to perspective being applied), we'll get a poor result. I suggest it would be better to go ahead and use the same scale computation as we'd use without perspective present. This may tend to give a larger scale than really needed, especially for the parts of an image that are disappearing towards a vanishing point, but (aside from a possible performance hit) it's likely to give a better-looking result than just using a unity scale.

Does this seem reasonable? In the specific example here, this change greatly improves the rendering I get.

Comment 6

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1806281 - If perspective is involved, don't force ChooseScale() to return (1.0, 1.0) but just apply this as a minimum. r=tnikkel

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:bhood, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 8

[Timothy Nikkel (:tnikkel)]

Attachment: car2.html

Comment 9

[Mayank Bansal]

is this still on the radar?

Comment 10

[Timothy Nikkel (:tnikkel)]

Several months back I did a bunch of code reading to understand how perspective works, how it is implemented in our frame tree, how we implemented it in the pre-webrender code, and how it is currently working with webrender. I was going to write a fix based on that understanding but got pulled away. I do plan to come back to this, and I do think there is a more correct solution then the posted patch.