Aliasing in screenshot of rescaled image
Categories
(Core :: Graphics, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox97 | --- | fixed |
People
(Reporter: mt, Assigned: tnikkel)
Details
Attachments
(4 files)
It appears as though screenshots capture resized images using nearest neighbor rather than whatever Firefox naturally uses.
STR:
Take a large image, preferably a line drawing with fine lines or something that could exhibit aliasing when resized.
Construct HTML and include the image with an override to its width. (My example was originally 731 pixels wide rendered at 127 pixels wide.)
<html><body>
<img src="image.png" width="127">
</body></html>
Capture a screenshot that includes the image. Compare to how the image is rendered in Firefox and observe differences. Any part of the image that is in a screenshot will exhibit aliasing.
|
||
Comment 1•2 years ago
|
||
Moving this over to the Graphics component for comment. Please send it back if there's something in our implementation we can do to make this a more consistent experience.
|
Assignee | |
Comment 2•2 years ago
|
||
Hmm, we don't use high quality scaling for images unless we are passed the flag when calling PresShell::RenderDocument. I wonder if there is a reason for that that I'm not thinking of right now. Should be an easy fix, we can either make that flag the default or create a new flag and get screenshots to pass the new flag to drawSnapshot to do that (which I'm assuming screenshots is using).
|
||
Updated•2 years ago
|
|
|
||
Comment 3•2 years ago
|
||
(In reply to Timothy Nikkel (:tnikkel) from comment #2)
we can either make that flag the default or create a new flag and get screenshots to pass the new flag to drawSnapshot to do that (which I'm assuming screenshots is using).
I'm assuming "high quality scaling" is going to be slower on large images. A flag we can pass into drawSnapshot would be good for Screenshots. In the past we did a lot of quality vs. performance tuning of screenshots. These days we are erring on the side of letting users make an informed choice rather than prevent them from making slow-but-high-quality screenshots. I'm not sure we'd provide UI for this flag, but would be a useful switch to flip if there are cases where the balance clearly tips in favor of prefering one or the other.
|
|
Assignee | |
Comment 4•2 years ago
|
||
(In reply to Sam Foster [:sfoster] (he/him) from comment #3)
(In reply to Timothy Nikkel (:tnikkel) from comment #2)
we can either make that flag the default or create a new flag and get screenshots to pass the new flag to drawSnapshot to do that (which I'm assuming screenshots is using).
I'm assuming "high quality scaling" is going to be slower on large images. A flag we can pass into drawSnapshot would be good for Screenshots. In the past we did a lot of quality vs. performance tuning of screenshots. These days we are erring on the side of letting users make an informed choice rather than prevent them from making slow-but-high-quality screenshots. I'm not sure we'd provide UI for this flag, but would be a useful switch to flip if there are cases where the balance clearly tips in favor of prefering one or the other.
When I used the term "high quality scaling" above it was perhaps a little misleading. When I said "high quality scaling" above I was referring to a specific flag we have in imagelib, it's meaning is perhaps overloaded, it means two things:
-imagelib is allowed to return a surface that is a different size then the intrinsic size of the image (we might have one already decoded or we might start decoding a new sized surface)
-when it does that the resulting pixels will use a higher quality downscale than nearest neighbour.
So with that understanding what we are currently doing will be slower in the common case.
currently:
-draw image to the screen with high quality scaling
-when screenshots asks for drawSnapshot without high quality scaling imagelib returns the image without high quality scaling, potentially requiring us to decode the image to the intrinsic size (which we didn't need for drawing to the screen)
always using high quality scaling for drawSnapshot:
-draw image to the screen with high quality scaling
-when screenshots asks for drawSnapshot with high quality scaling imagelib is able to return the same surface we used for drawing to the screen
If that seems reasonable to you, I think changing the default of drawSnapshot to use high quality scaling makes sense (assuming my patch reviewers agree :))
|
|
Assignee | |
Comment 5•2 years ago
|
||
|
||
Updated•2 years ago
|
|
|
Assignee | |
Comment 6•2 years ago
|
||
Most of the time this is just going to going to request the same frame that we used when painting to the screen. So it should be higher quality and faster in the common case.
This isn't the default for drawWindow or drawSnapshot. I know that it would be a waste to request high quality scaling without sync decode because if that triggers new decoding by the time the frame is ready it's too late to use it. drawSnapshot only supports syncdecoding so far, so that's not an issue, and we could disable this is async decoding was requested in the future.
Anything else I'm missing?
Depends on D133566
|
|
Assignee | |
Comment 7•2 years ago
|
||
We have reftest snapshot jobs that will test this.
Depends on D133567
|
|
Assignee | |
Comment 8•2 years ago
|
||
This test has a downscaled image, that is inside of an OOP iframe, and the iframe has a large transform scale to counter act the downscaled image inside the iframe. drawSnapshot does not take into account into scaling that happens to OOP iframes. If we don't pass the high quality scaling flag then we return the image as the intrinsic scale and we have a much better rendering here. If we pass the high quality scale we return the downscaled image, which we then try to upscale, and we get a worse rendering then before the patches of this bug.
So this is an edge that we will be making worse. If it's important then we should fix drawSnapshot to handle this.
Depends on D133568
Pushed by tnikkel@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/1c8deded6ea7 Create a high quality scaling flag for cross process paint and propagate it to dependencies. r=emilio https://hg.mozilla.org/integration/autoland/rev/20c0dc7a0122 Make drawSnapshot request high quality scaling by default. r=aosmond https://hg.mozilla.org/integration/autoland/rev/aa7bb6293726 Add test. r=emilio https://hg.mozilla.org/integration/autoland/rev/36dc359531fc Change annotation for gfx/tests/reftest/1724901-2.html. r=aosmond
|
||
Comment 10•2 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/1c8deded6ea7
https://hg.mozilla.org/mozilla-central/rev/20c0dc7a0122
https://hg.mozilla.org/mozilla-central/rev/aa7bb6293726
https://hg.mozilla.org/mozilla-central/rev/36dc359531fc
Description
•