perspective transforms and box shadow from css orange doesn't draw correctly

NEW
Assigned to

Status

()

defect
P2
normal
11 months ago
3 days ago

People

(Reporter: acupsa, Assigned: Gankro)

Tracking

(Blocks 1 bug)

63 Branch
Unspecified
All
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox63 disabled, firefox64 affected)

Details

Attachments

(5 attachments)

Version: 63.0a1
Build ID: 20180708220048
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0

[Affected Platforms]:
- Windows 10 64bit

[Prerequisites]
- Have WebRender enabled (gfx.webrender.all.qualified preference with true value).

[Steps to reproduce]:
1. Open Firefox Nightly (63.0a1) and navigate to cyanharlow.github.io/purecss-vignes 
2. Observe the rendered image.

[Expected result]:
- The image is correctly rendered.

[Actual result]:
- A part of the image is not correctly rendered.

[Notes]:
- Also reproducible with http://diana-adrianne.com/purecss-zigario/
- While resizing browser window or performing any action in the tab, creates browser lag.
- This issue is not reproducible with WebRender disabled.
- Attached a screenshot of the issue:
See Also: → 1459187
Blocks: 1474484
Priority: -- → P1
It would be nice to have a reduced test case of this brokenness. I've filed https://github.com/servo/webrender/issues/2881 about the broken rendering. https://github.com/servo/webrender/issues/2715 tracks the performance problem.

The brokenness here shouldn't be common enough for us to block the shield study.
Priority: P1 → P2
Blocks: stage-wr-trains
No longer blocks: stage-wr-nightly
Priority: P2 → P3
Can this still be reproduced?
Flags: needinfo?(andreea.cupsa)
The issue from attachment 8990701 [details] has likely been fixed by https://github.com/servo/webrender/pull/3073.

https://hg.mozilla.org/integration/mozilla-inbound/log/14c6b338e32c

last bad: mozregression --repo mozilla-inbound --launch a1a0f861a0ae --pref gfx.webrender.all:true -a http://diana-adrianne.com/purecss-vignes/

first good: mozregression --repo mozilla-inbound --launch 14c6b338e32c --pref gfx.webrender.all:true -a http://diana-adrianne.com/purecss-vignes/


There is one issue left: Half of the orange is a solid color at most zoom levels.
Flags: needinfo?(andreea.cupsa)
OS: Windows 10 → All
Summary: [WebRender Shield Study] Specific images entirely coded in HTML & CSS are not correctly rendered with WebRender enabled → (francine's sister) [WebRender Shield Study] Specific images entirely coded in HTML & CSS are not correctly rendered with WebRender enabled
Summary: (francine's sister) [WebRender Shield Study] Specific images entirely coded in HTML & CSS are not correctly rendered with WebRender enabled → (francine's sister correctness) [WebRender Shield Study] Specific images entirely coded in HTML & CSS are not correctly rendered with WebRender enabled
Looks like the problem here is a mix of perspective transforms and box shadow.
Summary: (francine's sister correctness) [WebRender Shield Study] Specific images entirely coded in HTML & CSS are not correctly rendered with WebRender enabled → perspective transforms and box shadow from css orange doesn't draw correctly
Assignee: nobody → emilio
Much likely this is the same as bug 1512537, which I said I was going to look at :-)
Depends on: 1512537
Emilio, bug 1512537 is fixed but this still shows up. Thoughts?
Flags: needinfo?(emilio)
Will take a look when I'm back from PTO on monday.

Also looking at this...

stealing since :emilio is busy with more important stuff atm

Assignee: emilio → dmalyshau
Flags: needinfo?(emilio)

Dzmitry has debugged this enough to understand that it is rare. Demoting to P4

Priority: P3 → P4

I think the issue comes from the way we interpolate clip UV coordinates for the case where the clip space is perspective-transformed. Our current approach involves special code for 2D un-projection of a local point into the clip plane ("get_node_pos" in shaders), and one of the following may be happening:

  1. the un-projection code doesn't work with perspective: it assumes the space is just a rotated/scaled plane, which isn't exactly the case here
  2. these UV coordinates aren't interpolated with perspective correction
Blocks: wr-67
No longer blocks: stage-wr-trains
Priority: P4 → P2
Blocks: wr-68
No longer blocks: wr-67
Assignee

Updated

11 days ago
Assignee: dmalyshau → a.beingessner
Assignee

Comment 14

11 days ago
Posted patch test.yamlSplinter Review

Attaching a simple yaml demonstrating how we mess up box-shadows in perspective so I can easily run this on different machines.

Assignee

Comment 16

11 days ago

Ok so dug through this a bit and we seem to have figured this out. Basically, we are currently overly relying on "preserve-3d" to force us to render things in local space / intermediates. Notably, the "CS" family of shaders aren't supposed to be run with perspective -- they're supposed to be drawn in local space and then have the perspective applied with brush_image.

The case in question draws a box shadow inside a perspective transform without any preserve_3ds. The pipeline then concludes nothing needs to be composited and we get messed up shadows. The attached test-case demonstrates that just adding a preserve-3d node fixes everything. But we can't rely on users adding these, so we need to add some more robust automatic detection.

kvark has suggested this should be done when we're allocating render tasks.

To clarify on my suggestion, in the render task chain Primitive -> BoxShadow -> Output, when there is perspective transformation involved we are currently doing the transform in Primitive -> BoxShadow step, which is done via a "cs_" shader that doesn't support perspective, while BoxShadow -> Output is done via an image (or blend) brush without transformation. Instead, we should be doing Primitive -> BoxShadow without transformation and then apply the perspective to the image/blend shader in the second step.

You need to log in before you can comment on or make changes to this bug.