1671784 - Rotate clip-path background (CSS) will render outlines of element from ff82

Status: VERIFIED FIXED

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

Description

[u672315]

Attachment: test.html

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0

Steps to reproduce:

"Transform rotate" an element with clip-path background, bug appears from FF82beta and in FF83.0a1, see test file and screenshots.

Actual results:

Outlines of element start to show

On FF 81 it is not detected with webrender off.
On FF 82 and 83 with both webrender on or off, if not initially, they will appear when for example the window is "dragged to another size"

Expected results:

Outlines of element should not show

Comment 1

[u672315]

Attachment: ff83-before.PNG

Comment 2

[u672315]

Attachment: ff83-after.PNG

Comment 3

[u672315]

Attachment: ff83-WebRend-on.PNG

Comment 4

[Alice0775 White]

I can reproduce on Nightly83.0a1 Windows10.

Comment 5

[Alice0775 White]

Regression window(WebRender on):
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=0fedcd9cdd51f06c9e177a1b81c04c7ac93e27bf&tochange=d0221689e8e9a720dca3bdc7f4c3371c09f6626c

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 8

[papoxa8620]

Any news on this one?

Comment 9

[derevag734]

@posters
Don't worry about it. If it looks bad just change to Chromium based browser. Devs here don't care.
Tried demo on chrome looks great! Don't waste time here.

Chrome also support pwa installation, and ff's main concern is still if webrender will work on 4 years old laptops... no progessiveness. They have already given up being a viable option. As it is there is only 2 browser candidates left. Webkit and Chromium. The fox is dead.

Yes a bug like this make it look like shit on ff, loading elements with JavaScript and doing animation with clip-path, forget it. But hardly any use ff so no one cares!

Strangely the browser is the brand for ff, still all the resources dosen't seem to be utilized for it. Restore ff browser first as a viable alternative to chrome then focus on idiot tasks like phone-os where windows, ubuntu and ff all faild... They don't have the user trust..
Why? Well just try ff browser, now would you buy a phone running ff-os for $500 or more? I would not.

Forget about ff, the fox is dead! Explorer, ff, now browser environment is down to two... make it easy for you and go with what works! And enjoy life!!

Comment 10

[Glenn Watson [:gw]]

(In reply to papoxa8620 from comment #8)

Any news on this one?

The best fix for this will be to ensure that the off-screen surface establishes a raster root, and the image clip mask gets applied in that local space before being drawn in to the parent picture.

The first step of that work is https://bugzilla.mozilla.org/show_bug.cgi?id=1696842 - this ensures that all off-screen surfaces establish a raster root. However, that patch was backed out for causing some unexpected performance regressions, which need further investigation before that can be re-landed.

Comment 12

[foxotogi]

Yepp this isn't looking good, and it has been around for a while. Can we get a target release?

Comment 13

[Glenn Watson [:gw]]

All the work to make off-screen surfaces establish raster roots has landed now, so I'll take a look again at this and see why it still happens.

Comment 14

[Glenn Watson [:gw]]

The issue is that the clip-mask is applied in the post-transform space, which is causing accuracy issues (since it's applied on the WR stacking context, not the primitive).

There's a couple of options here:

1. Try to be more accurate in handling clip-mask edges when there is a non-axis-aligned transform present.
2. Have the clip-mask be applied in the local space of the off-screen surface, so it's axis-aligned with the content it is masking.

(1) is likely to be a smaller change, but difficult to get 100% right - we could probably get it mostly right, but there will still be edge cases that are difficult to get pixel-perfect. (2) is a much better solution, it will give pixel-perfect results, but I'm not sure if this is a complex change to make.

Next step will be to look in to what's involved in option (2) and see how much work would be involved to do this.

Comment 15

[Glenn Watson [:gw]]

A third option:

Make the clip-mask implementation instead be a filter-style property in the WR API. This would implicitly mean the mask is applied in the same local space as the stacking context, prior to the transform being applied.

Comment 16

[Ashley Hale [:ahale]]

Looking at how I can fix this bug, expect some questions and rambles on what I learn :)

Comment 17

[Ashley Hale [:ahale]]

Current plan of attack (per discussion with :gw ) - implement new filter type (Filter::ImageMask) to apply a clip mask in the shader in a better way that won't have this class of rendering artifact.

Rough steps planned so far:

• Prepare a wrench reftests yaml file with help from :gw to test the new filter (done).
• Stub out the new filter case in each place it is used (done).
• Implement the stubs for the filter that are hit in testing.
• Make a list of stubs not hit by any tests, as these may indicate missing test coverage.
• Implement the new filter in the shader code, hooking up a new sampler for the mask.
• Add a config variable for whether to use the new filter type for clip masks and make the code conditional on that.
• Change the way clipmasks are fed to WebRender to use the new filter type (based on the config variable).
• Verify reftests work correctly.
• ?

Comment 22

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S4. However, the bug has 5 duplicates.
:ahale, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 23

[Ashley Hale [:ahale]]

Increased severity due to 5 duplicate bugs.

Comment 24

[georg.pukk]

Putting clipped or masked element in .parent { border-radius: 0.01px; overflow: hidden; } removes the outline.

Comment 25

[Ashley Hale [:ahale]]

That seems like a novel workaround, my focus however is on making it look right every time without workarounds :)

Status: Nearly looks right with my code changes, but there are polygon gaps between ImageMask tiles at some scroll offsets and zoom levels, so there's something doing some coordinate rounding in the primitive handling that I need to fix.

Comment 26

[mark.j.fisher]

(In reply to georg.pukk from comment #24)

Putting clipped or masked element in .parent { border-radius: 0.01px; overflow: hidden; } removes the outline.

Thanks for the workaround Georg (psst Ashley I think the workaround was aimed at devs struggling with the bug like me, not you as the assignee).

Comment 27

[mark.j.fisher]

(In reply to georg.pukk from comment #24)

Putting clipped or masked element in .parent { border-radius: 0.01px; overflow: hidden; } removes the outline.

Seems like you mean to rotate the parent instead. However I found I also needed to add transform: rotate(0deg) to the child too to hide the artifact.

Comment 28

[georg.pukk]

(In reply to mfishe from comment #27)

(In reply to georg.pukk from comment #24)

Putting clipped or masked element in .parent { border-radius: 0.01px; overflow: hidden; } removes the outline.

Seems like you mean to rotate the parent instead. However I found I also needed to add transform: rotate(0deg) to the child too to hide the artifact.

For me it works if I rotate the .child itself.
However, it seems that position other than static on either element also plays a role.

Comment 29

[mark.j.fisher]

(In reply to georg.pukk from comment #28)

(In reply to mfishe from comment #27)

(In reply to georg.pukk from comment #24)

Putting clipped or masked element in .parent { border-radius: 0.01px; overflow: hidden; } removes the outline.

Seems like you mean to rotate the parent instead. However I found I also needed to add transform: rotate(0deg) to the child too to hide the artifact.

For me it works if I rotate the .child itself.
However, it seems that position other than static on either element also plays a role.

Ah yes, you are right. I had position: absolute on the .parent which was what made rotation by 0 necessary on the child.

Comment 31

[f.xrave]

+1 on this. Happening when i try to rotate a button styled with unocss-icons + iconify + tailwind on Windows 10 109.0 (64-bit) firefox.

Comment 32

[thomas.cauquelin]

+1. Also trying to rotate a div with unocss-icons + iconify + tailwind on macOS Ventura 13.1 and Firefox 109.0.1 (64 bits).

Comment 33

[bneo]

+1. I see this problem on my website too. https://shadersmods.com/

Comment 34

[Daniel Berndt]

For people looking for workarounds:
I managed to avoid this issue by applying {padding: 1px, margin: -1px} to the element with the clip-path and box-shadow: 0 0 1px transparent to the child.

Comment 35

[silverwind]

Attachment: mask-rotate.html

Reproduction using mask-image and rotate.

Comment 36

[silverwind]

Attachment: Rendering of mask-rotate.html

Here's the rendering of attached mask-rotate.html to showcase this bug is not limited to clip-path, but also happens when mask-image and tranform: rotate are applied together. Same use case renders without this subpixel "border" in Blink.

Comment 37

[Glenn Watson [:gw]]

One the work in https://bugzilla.mozilla.org/show_bug.cgi?id=1823579 is complete, we should be in a much better position to fix this case. That work should be complete in the next 2-3 weeks.

Comment 38

[Glenn Watson [:gw]]

Both the repro in comment #1 and comment #36 appear fixed for me with the patches in #1849530 and #1849661 applied. There is a try build with these at [1] if anyone wants to do some local testing, build artifacts should be available soon.

I think there are still some other edge cases that can cause this to occur, but I will fix those if / when they are reported as separate bugs, which should be much simpler after the work done to fix this most common case.

[1] https://treeherder.mozilla.org/jobs?repo=try&revision=9d9c1d8c2dd5fbcc45726bb0afb9e5b04c8de5a9

Comment 40

[Mayank Bansal]

Attachment: Screenshot 2023-08-29 195743.png

With the latest nightly (that contains the fix from bug 1849661), I can still repro the dotted lines on the first testcase by pinch-zooming and maybe panning on the image. It may also be dependent on some parts of the zoomed-out testcase being beyond the visible part of the page.
:gw, let me know if you want this to be tracked in a new bug.

Edit2: The second testcase also renders the dotted line with pinch-zoom and maybe some panning.

Comment 41

[Mayank Bansal]

Attachment: bug2.png

Comment 42

[Glenn Watson [:gw]]

Yes, let's track that in a separate bug - I know what the cause is, and it's a different issue than what was resolved in this bug.

Comment 43

[Mayank Bansal]

(In reply to Glenn Watson [:gw] from comment #42)

Yes, let's track that in a separate bug - I know what the cause is, and it's a different issue than what was resolved in this bug.

Filed bug 1850869

Comment 44

[Ardelean Oana, Desktop QA [:oardelean]]

Reproducible on a 2023-08-24 Nightly build on Windows 10.
Verified as fixed on Firefox 119.0b2(build ID: 20230928191344) and Nightly 120.0a1(build ID: 20230928215127) on Windows 10, macOS 12, Ubuntu 22.