1743761 - Large images are blurry at first zoom-in

Status: VERIFIED FIXED

(Core :: Graphics: WebRender, defect)

Description

[Fanolian]

Attachment: Blurry image at first zoom-in.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:96.0) Gecko/20100101 Firefox/96.0
Build ID: 20211130214422

This is essentially bug 1738267 comment 2 minus the "image not displayed" part.

Steps to reproduce

1. Open https://bug1738267.bmoattachments.org/attachment.cgi?id=9248305 in (current/new) tab in a new profile.
2. Left click on the image to zoom to the original size.

Actual result

At the first zoom-in, the image is blurry. Subsequent zoom-ins are working fine. To re-create the issue, simply reload the image.
Unlike bug 1738267, the image does not go blank after a reload.

Expected result

Image is not blurry at its original size.

Additional Notes

Here and here are other images that exhibits the same bug.

Workaround

1. Zoom out and zoom in again will show the correct image.
2. Move cursor to scroll bar. I tried moving cursor to address bar but it doesn't work.

System info

Windows 10 21H2 19044.1348 (latest)
Nvidia GTX760 driver 472.12 (latest)
Display resolution: 1920 x 1080

Regression

Last good Nightly: 2021-11-26
First bad Nightly: 2021-11-27
pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c0bd08bc5b382cd006a39fb3723025bb3f29cf11&tochange=afed7ee7a5dcee09542f3157224a54057527d842

Bisecting autoland builds:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=56a1fce20849e569b75856301c801f89a0d6e0b9&tochange=3fe9e1643aafa1f8f5ba19b012b90b0d39a422b5

This is regressed by bug 1711061 (relanded version).

Comment 1

[Fanolian]

Attachment: about_support.txt

about:support of my new profile. This bug can be reproduced with Fission enabled even though it is disabled in this new profile.

Comment 2

[Fanolian]

(In reply to Fanolian from comment #0)

This is regressed by bug 1711061 (relanded version).

This should be:
This is regressed by bug 1711061 again in the relanded version.

Comment 3

[Release mgmt bot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1711061

Comment 4

[Andrew Osmond [:aosmond] (he/him)]

The cached ImageProvider returns the same image, but we would have gotten a different ImageProvider if we invalidated, which we suppress since the ImageProvider did not change. We need to indicate that the initial ImageProvider is actually just a substitute so we know to always invalidate in this case.

Comment 5

[Andrew Osmond [:aosmond] (he/him)]

Attachment: Bug 1743761 - Ensure we invalidate substituted images when the preferred size is ready.

Previously with ImageContainers, we would put the new preferred surface
into the ImageContainer. When we check if we should invalidate, it would
have a different image key, and hence invalidate the image frame and
schedule a paint.

With ImageProviders, it returns the same key in this case, because the
ImageProvider represents a particular surface. As such, we need to
actually track when we get a substituted ImageProvider, and invalidate
the image frame more aggressively to ensure we get the preferred size.

Comment 7

[Andrew Osmond [:aosmond] (he/him)]

Attachment: Bug 1743761 - Ensure we invalidate substituted images when the preferred size is ready.

Previously with ImageContainers, we would put the new preferred surface
into the ImageContainer. When we check if we should invalidate, it would
have a different image key, and hence invalidate the image frame and
schedule a paint.

With ImageProviders, it returns the same key in this case, because the
ImageProvider represents a particular surface. As such, we need to
actually track when we get a substituted ImageProvider, and invalidate
the image frame more aggressively to ensure we get the preferred size.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/356c52182625
Ensure we invalidate substituted images when the preferred size is ready. r=tnikkel

Comment 9

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/356c52182625

Comment 10

[Catalin Sasca, QA [:csasca]]

Reproduced the issue on Firefox 96.0a1 (2021-12-01) under Ubuntu 20.04 by following the STR from Comment 0.

The issue is fixed on Firefox 96.0b3 and Firefox 97.0a1 (2021-12-10). Tests were performed on Ubuntu 20.04, Windows 11 and macOS 11.6.1.