1892398 - Quad shaders use a mix of device and layout coordinate spaces

Status: RESOLVED FIXED

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

Description

[Nicolas Silva [:nical]]

If a quad primitive uses the direct rendering strategy, the shader receives layout-space coordinates and a transform. If the primitive is segmented, however (via tiling or a nine-patch), then for pattern and composite segments the shader receives coordinates in device space and no transform. quad render tasks look like they work with layout space as well.

This causes issues because the pattern is built before the quad rendering strategy and always in layout space. We have to either consistently use layout space coordinates or make it possible to transform patterns and pass a mix of transformed and non-transformed patterns depending on the segment.

Comment 1

[Nicolas Silva [:nical]]

Attachment: Bug 1892398 - Handle quad nine-patches in a single loop. r=gw

This patch mainly extracts the direct/indirect quad segment separation in the scratch buffers from D207657

Comment 2

[Nicolas Silva [:nical]]

Attachment: WIP: Bug 1892398 - WIP - layout space nine-patches

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/70246310c93b
Handle quad nine-patches in a single loop. r=gw

Comment 4

[Nicolas Silva [:nical]]

Attachment: Bug 1892398 - Remove unused prim_spatial_node_index in PrimTask. r=gw

Comment 5

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/70246310c93b

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5106d4f90040
Remove unused prim_spatial_node_index in PrimTask. r=gw

Comment 7

[Nicolas Silva [:nical]]

Attachment: Bug 1892398 - Rename a couple of render task variables for clarity. r=gw

Comment 8

[Nicolas Silva [:nical]]

Attachment: Bug 1892398 - Don't hard-code that quad segments with a source render task are alpha blended. r=gw

Not immediately necessary but when cached quads or patterns that read a texture are implemented, There will be opaque segments taking render tasks as input. Currently the code is a bit error prone because some parts of the code advertize a certain behavior that is later overruled. This patch makes things more explicit and flexible.

Comment 9

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/5106d4f90040

Comment 10

[Nicolas Silva [:nical]]

Attachment: WIP: Bug 1892398 - (WIP) Allow building the pattern in prepare_quad

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/bedb22762bf0
Rename a couple of render task variables for clarity. r=gw
https://hg.mozilla.org/integration/autoland/rev/986045c4cb94
Don't hard-code that quad segments with a source render task are alpha blended. r=gw

Comment 12

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/bedb22762bf0
https://hg.mozilla.org/mozilla-central/rev/986045c4cb94

Comment 13

[Glenn Watson [:gw] | PTO until 29th April]

Attachment: Bug 1892398 - Supply local space coords to compositing quads when drawing patterns

Comment 14

[Nicolas Silva [:nical]]

Attachment: Bug 1892398 - Rename unclipped_surface_rect and add comments about incorrect/missing pieces. r=gw

Comment 15

[Nicolas Silva [:nical]]

Attachment: Bug 1892398 - Supply local space coords to compositing quads when drawing patterns. r=gw

Same as https://phabricator.services.mozilla.com/D209622 with a few extra fixes.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/31d3644cddd1
Rename unclipped_surface_rect and add comments about incorrect/missing pieces. r=gw

Comment 17

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/31d3644cddd1

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4b3b1066a855
Supply local space coords to compositing quads when drawing patterns. r=gw

Comment 19

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/4b3b1066a855