Firefox shows white area while downloading/rendering PNG image
Categories
(Core :: Graphics: WebRender, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr102 | --- | unaffected |
| firefox108 | --- | wontfix |
| firefox109 | --- | wontfix |
| firefox110 | --- | wontfix |
| firefox111 | --- | wontfix |
People
(Reporter: brille1, Unassigned)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression)
Attachments
(1 file)
|
3.23 MB,
image/gif
|
Details |
Issue evidence screencast
While Firefox renders a not yet fully downloaded PNG image, it renders a white space glitch.
This rendered white space yields a strong, undesired flickering experience on dark web pages.
For a living example, visit https://alex-bender.de/ (it's currently WIP)
|
||
Comment 1•2 years ago
|
||
Hello, thank you for the bug report!
I managed to reproduce this issue on:
- Nightly 110.0a1;
- Firefox 109.0b7;
- Firefox 108.0.1;
Tested and reproduced on:
- Windows 10;
- Ubuntu 22( have to try a couple times to catch it);
- macOS 12( with CMD+Shift+R);
Moving the Product to "Core" and the Component to "Graphics". Please change if there's a better fit.
Setting as NEW so the developers can have a look.
|
||
Comment 2•2 years ago
|
||
bad = image is decoded from the top to the bottom on an unexpected white background. In Chromium, the background is transparent/dark.
good = dark page background until the image is visible.
$ mozregression --good 2021-12-01 --bad 2022-12-30 -a https://alex-bender.de/
13:13.83 INFO: Last good revision: d4adb945d17bda4740ff64315867998a85c9852f
13:13.83 INFO: First bad revision: 846e7307e1a3894c84993f4d96d178de6917681e
13:13.83 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d4adb945d17bda4740ff64315867998a85c9852f&tochange=846e7307e1a3894c84993f4d96d178de6917681e
846e7307e1a3894c84993f4d96d178de6917681e Timothy Nikkel — Bug 1231622. Allow drawing CSS images that don't have a complete frame. r=aosmond
|
||
Comment 3•2 years ago
|
||
I presume what's going on here is that when the PNG is only partially decoded, we're rendering a default white background in the remainder of the frame. If the partially-decoded image had a transparent background instead of white, the site's dark <body> background would "show through" the un-decoded area instead.
So the site might be able to work around this by ensuring that the PNG image actually has an alpha channel? But it would be nice to improve the user experience with an opaque image, too.
Experimentally, I see that patching nsPNGDecoder::GetTransparencyType so that it defaults to returning eFrameRect instead of eNone results in a nicer experience here, avoiding the flash of white when the image isn't yet complete. But there's presumably some performance cost to this, and perhaps other side-effects as well?
diff --git a/image/decoders/nsPNGDecoder.cpp b/image/decoders/nsPNGDecoder.cpp
--- a/image/decoders/nsPNGDecoder.cpp
+++ b/image/decoders/nsPNGDecoder.cpp
@@ -139,7 +139,7 @@ nsPNGDecoder::TransparencyType nsPNGDeco
return TransparencyType::eFrameRect;
}
- return TransparencyType::eNone;
+ return TransparencyType::eFrameRect;
}
void nsPNGDecoder::PostHasTransparencyIfNeeded(
Maybe we could provide some way for the caller that's using the PNG decoder to specify what default background should be used to fill not-yet-decoded areas of the frame? But what's "behind" the image might not just be a dark background; it could be a gradient or an entirely different image, for instance. So perhaps it really is most appropriate for it to be transparent in all cases.
Thanks to you all for taking the time to solve this issue!
What do you think, may this be fixed soon? I'm implementing an image gallery for that website. I guess, none of the photographer's pictures I got will be with a transparent background. I wouldn't want to spend the time converting all these if it's foreseeable that this glitch will be fixed in the next few weeks or months.
|
||
Updated•2 years ago
|
|
|
||
Updated•2 years ago
|
|
|
||
Comment 5•2 years ago
|
||
Out of curiosity, I pushed the hack mentioned in comment 3 to tryserver to see what would happen. Unsurprisingly, it results in a bunch of gtest failures, though I don't know what their real significance is. Reftests seem to have fared pretty well, though.
Anyhow, I don't really know anything about this, so I'll leave it for others to figure out a reasonable solution here.
|
||
Updated•2 years ago
|
|
||
Comment 6•2 years ago
|
||
Ah, interesting, for regular img elements this is actually a regression from webrender. The regressing bugs were just enabling partial image drawing for background imgs.
So for image surfaces we write 255 in the alpha channel of images that are opaque and use a format that doesn't include alpha even though the alpha should be ignored because I believe some issues with skia.
Then when drawing we are careful to only draw pixels that we have written into
With webrender we bypass that path and just return the image surface directly and share that across process without any info about what part of it has decoded data.
We might have to pass the "which pixels are decoded" info to the gpu process to fix this, not sure if there is a better way.
For the site author you can work around this behaviour by making your png be transparent (even if all the pixels are opaque).
I save the images with transparency now, yet the white glitch still exists.
|
|
||
Comment 8•2 years ago
|
||
(In reply to Axel from comment #7)
I save the images with transparency now, yet the white glitch still exists.
Is the png live on the website right now? Or where can I inspect this png you saved with transparency? The one I just fetched from https://alex-bender.de/ is still marked as an opaque png, so if that is the one saved as transparent your app still saved it as opaque.
I just downloaded the png from the website, opened it in gimp and exported it as an RGBA file. I was able to reproduce the white with the downloaded file but with the file I altered to be RGBA the problem went away. So if you are still seeing the problem it is likely that the png didn't get saved in RGBA format.
Yes, I always upload the latest version, so you (and I) can observe the effect. Actually, I need the download latency to see the effect.
|
|
Reporter | |
Comment 10•2 years ago
|
||
is still marked as an opaque png
Oh … That's strange. I saved it using Corel Photo Paint with Transparency checkbox checked. Photoshop is also telling me that the image has been saved with transparency. I'll check and get back with the results …
I need to look for a tool that's providing the PNG meta data for me, so I can verify what has been saved.
|
||
Updated•2 years ago
|
|
|
Reporter | |
Comment 11•2 years ago
|
||
@tnikkel: FWIW: I tested with PhotoShop, Corel Photo Paint and other tools. They all don't save the image with transparency even if I set the Save With Transparency checkbox, as the image data doesn't have any transparency in the image. I guess they do that to reduce file size by omitting the additional Alpha channel from the image data.
|
|
||
Comment 12•2 years ago
|
||
Okay, using gimp worked for me. I verified by using the "file" command line tool, it reports
PNG image data, 805 x 917, 8-bit/color RGBA, non-interlaced
the RGBA is the key part, if it says RGB then it's not transparent.
|
||
Updated•2 years ago
|
|
||
Updated•1 year ago
|
|
||
Updated•1 year ago
|
|
||
Comment 13•10 months ago
|
||
Still having this issue as of Firefox 116. Huge bummer for darkmode, forces me to use chrome
|
||
Updated•10 months ago
|
|
||
Updated•3 months ago
|
|
|
||
Comment 15•1 month ago
|
||
Is this essentially a dup of 1556156?
|
|
||
Comment 16•1 month ago
|
||
(In reply to Jeff Muizelaar [:jrmuizel] from comment #15)
Is this essentially a dup of 1556156?
Yes.
Description
•