Closed Bug 1768058 Opened 3 years ago Closed 2 years ago

Loading particular image with background-size: cover causes opacity to break

Categories

(Core :: Graphics: WebRender, defect, P3)

Product:
Core
Component:
Graphics: WebRender
Version:
Firefox 100
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
102 Branch
Tracking Flags:
Tracking Status
firefox-esr91 --- wontfix
firefox100 --- wontfix
firefox101 --- wontfix
firefox102 --- fixed

People

(Reporter: danielstone411, Assigned: bradwerth)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression)

Attachments

(4 files)

example.png
1.33 MB, image/png
Details
testcase
321 bytes, text/html
Details
testcase 2
403 bytes, text/html
Details
Bug 1768058: Add wrench tests for opacity on stretched images.
48 bytes, text/x-phabricator-request
Details | Review
Attached image example.png —

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:100.0) Gecko/20100101 Firefox/100.0

Steps to reproduce:

Open the following HTML file in Firefox 100.0.

The page loads an image with custom dimensions from Unsplash.com. The opacity style is not respected when background-size is set to cover.

test.hml:

<html>
<div style="background-image: url(&quot;https://images.unsplash.com/photo-1520258355794-b4023f5ccf41?ixid=MnwxMTI1OHwwfDF8cmFuZG9tfHx8fHx8fHx8MTY1MTczNzc1OQ&amp;ixlib=rb-1.2.1&amp;q=85&amp;w=3120&quot;); opacity: 0.5; height: 100%; width: 100%; background-position: 50% 50%; background-size: cover;"></div>
</html>

The issue does not appear for all unsplash images, and does not occur when the "ixid" query parameter is removed.

Actual results:

The image displays as if opacity: 1

See example.png

Expected results:

The image displays faded as if opacity: 0.5

This seems to be somewhat related to the size of the div.

On my Macbook, the opacity stops working when the window is resized such that the div is wider than 1560. This is exactly 4 times less than the width of the image.

window.devicePixelRatio is 2 in case that helps.

Component: Untriaged → Layout
Product: Firefox → Core
Component: Layout → Graphics: WebRender
Status: UNCONFIRMED → NEW
Ever confirmed: true

Regressed by bug 1669840. However it's still broken in latest nightly so bug 1723469 did not fix this.

Regressed by: sw-wr-perf-opacity
Attached file testcase —

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

status-firefox100: --- → affected
status-firefox101: --- → affected
status-firefox102: --- → affected
status-firefox-esr91: --- → affected

:bradwerth, since you are the author of the regressor, bug 1669840, could you take a look?
For more information, please visit auto_nag documentation.

Flags: needinfo?(bwerth)

It definitely seems like it's the same problem as bug 1723469 except we don't know what the internal webrender limit is that we are hitting, ie the condition in the gecko display list code to avoid hitting the internal webrender limit isn't correct.

Playing around with the background size on this testcase it seems like the internal limit is based on the area of the total resized image. For example, if the width is 1265 then the we hit the internal webrender limit when the height becomes 3419 and not a pixel sooner. If the width is 1559 then the height hits the limit at 2774. 1265 * 3419 = 4325035, 1559 * 2774 = 4324666. And further attempts with other values that product stays about the same.

See Also: → 1768340
Attached file testcase 2 —

Testcase 2 is testcase 1 except with a different sized large image. I get totally different limits for width and height and the product is quite different. Seems like we are hitting some weird limit or bug somewhere.

can_promote_to_surface always returns false here
https://searchfox.org/mozilla-central/rev/b72e9d7d63bf499d1d8168291b93d4ec7fde236e/gfx/wr/webrender/src/picture.rs#3090
because the PrimitiveFlags::PREFER_COMPOSITOR_SURFACE flag is not set in both the buggy and working case. So it doesn't seem to be related to that.

Has Regression Range: --- → yes

I'll look into it.

Assignee: nobody → bwerth
Severity: -- → S3
Priority: -- → P3

Ran into a similar issue this week, so hopefully the following will be help full.

I am using some vector graphics as a backgrounds on various element and adding opacity to create the desired affect. Works as expected until I view it on my 5k monitor at a width greater than 1816px. Issue only appears in FF, currently using version 100.0 on MacOS, but does not happen in Safari, Chrome or MS Edge. or on mobile, or on a 1080p monitor. So thinking it has something to do with larger high res screens.

Also if you use the built in take a screen shot feature in FF, the screen shot renders correctly, so super odd. Here are some screen shots.

This is how it should display:

This is what is happening on 5k monitor with browser window over 1816px wide:

(In reply to me from comment #11)
Sorry markdown for images didn't work.

Blocks: wr-correctness

Since the screen shots didn't work and the page is now public, you can view it here https://www.actualtechmedia.com/techslayers/. The backgrounds with the issue are behind the contact form and in the bottom light blue call to action.

There is some strange limit being hit that isn't obviously based on the destination rect. Attachment 9276173 [details] fails when width > 780 or height > 1386. https://www.actualtechmedia.com/techslayers/ fails when width > 1216.

Flags: needinfo?(bwerth)

Glenn, why do we not submit image_data.color.a for the opacity value here? Doing this in a test build gets me correct opacity for the larger image sizes, but the opacity is applied twice when the images are smaller -- hitting whatever cutoff there is in WR for applying opacity directly to images.

Flags: needinfo?(gwatson)

I'm not sure - where else does the opacity value get used / supplied? I guess it must be somewhere since it's applied twice for small images?

Flags: needinfo?(gwatson)

I believe I've figured this out, such that I can fix Bug 1752919 and this will be closeable as a duplicate. The issue is that when images are large enough to be tiled, we unilaterally push white as the image color which ignores the opacity that might have been applied to the image color. I'll do the fix in Bug 1752919 so I can also remove references to that bug from the code comments.

Depends on: 1752919

Bug 1752919 fixed the opacity issues for tiled images, so this just adds tests that
replicate the testcases that spotted the issue.

Pushed by bwerth@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/99689bf1647f Add wrench tests for opacity on stretched images. r=gw

https://hg.mozilla.org/mozilla-central/rev/99689bf1647f

Status: NEW → RESOLVED
Closed: 2 years ago
status-firefox102: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → 102 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: