803703 - High quality image resizing doesn't work for 'position: fixed' images

Status: VERIFIED WORKSFORME

(Core :: Graphics: Layers, defect)

Description

[bugzmailer]

Attachment: testcase

I don't know if this is a known limitation, but 'position: fixed' imgs don't get high quality filtering. See testcase.

Remove 'position: fixed;' from the style declaration to see how it should look.

Comment 1

[Joe Drew (not getting mail)]

Ugh. I am 95% sure this is because we're upgrading position:fixed images to ImageLayers, and thus only drawing them using the layers system, not using Imagelib itself. Unfortunately I don't know if it's possible to know what size we want to draw images at when we call GetImageContainer on them; Matt/Rob, do you know?

Comment 2

[Matt Woodrow (:mattwoodrow)]

That makes sense, yeah.

Very close, yes, it shouldn't be hard to achieve.

http://mxr.mozilla.org/mozilla-central/source/layout/base/FrameLayerBuilder.cpp#1535

In PopThebesLayerData we're calling CanOptimizeImageLayer (which is what calls GetImageContainer on the RasterImage), and then just after that we call nsImageFrame::ConfigureLayer, which computes the destination size of the image and the scale to apply.

Comment 3

[Den Rivera]

...ping?

I see a lot of image-related improvements lately, might want to attack this while it's hot.

Comment 4

[Elbart]

The problem mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=1060200#c30 is actually this bug. After removing "position: fixed" from the testfile there, the issue was gone.

The bug here was made less severe by bug 1039926 and another bug around Sept 1st I cannot pinpoint, after which the image was at least hq-scaled upon loading or hitting ctrl+f5, but only until the user either switches to a different tab or refreshes (f5 or ctrl+r) the page, after which the lq-scale is shown.

Only a full reload with ctrl+f5 changes back to the hq-scaled image.

Comment 5

[Elbart]

FWIW, position:sticky has the same issue.

Comment 6

[Elbart]

Also since bug 1039926: When marking the lq-scaled image, the hq-scaled image is shown, and it stays after unmarking the image.
Switch away from and back to the tab, and the lq-scaled image is shown again.

Comment 7

[Matt Woodrow (:mattwoodrow)]

I just had a quick look at this, doesn't look like it'd be too hard to implement.

I think the main change we'd need is to move mImageContainer from RasterImage into imgFrame. This also includes the UpdateImageContainer code to invalidate the cached data. I'm also not sure why we attempt to recreate the ImageContainer immediately, instead of just nulling our pointer and waiting until the next paint. The current code has to deal with re-entry which wouldn't happen when dropping the pointer.

We also probably need an alternative version of LookupFrame that additionally takes size and filter parameters and finds the appropriate imgFrame. We could use this at the callsite of DrawWithPreDownscale instead of handling scale manually there too.

Adding a size parameter to imgIContainer::GetImageContainer and passing it from layout doesn't look hard.

What do you think seth?

Comment 8

[Elbart]

The patch for Bug 1069369 broke the testcase completely for me.
The lq-scaled image is only rendered partially, and it's never hq-scaled.

Last good revision: 1735ff2bb23e (2014-09-25)
First bad revision: 818f353b7aa6 (2014-09-26)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1735ff2bb23e&tochange=818f353b7aa6

Last good revision: 9285d6b729bd
First bad revision: bf65863441be
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=9285d6b729bd&tochange=bf65863441be

Last good revision: 04e0091575b9
First bad revision: df78a0e806d7
Pushlog:
https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=04e0091575b9&tochange=df78a0e806d7

Comment 9

[Elbart]

The try-build of bug 1130328 comment 21 fixed the loading of the image, but scaling is still broken.

Comment 10

[Alice0775 White]

Attachment: testcase_not_fixed_even_if_landing_Bug1182929.zip

top-left: 'position: static'
top-right: 'position: fixed'   --- Bug
bottom-left: 'position: absolute'  --- Bug

Comment 11

[Gregory Pappas [:gregp]]

Alice, are you still able to reproduce the issue with the test case from comment 10?

Comment 12

[Alice0775 White]

I cannot reproduce this on 115.3.0esr, 118.0.1, 119.b4 and 120a1.
This seems to have been fixed in Firefox 48.

Comment 13

[Gregory Pappas [:gregp]]

Thanks for verifying!