1682195 - (sw-wr-perf-clip-image) cs_clip_image is slow in SW-WR

Status: RESOLVED FIXED

(Core :: Graphics: WebRender, task)

Description

[Lee Salzman [:lsalzman]]

The cs_clip_image shader shows up as slow in some profiles

Comment 1

[Lee Salzman [:lsalzman]]

Attachment: Bug 1682195 - Use scissoring to restrict cs_clip_image rather than discard. r?gw,nical

cs_clip_image renders the entire target-space sub-rect, and then use discard against
the local-space bounds to ensure the primitive gets tripped down to its actual footprint
within the larger target-space sub-rect. This can be fairly wasteful and slow.

This patch restructures things so that we essentially render with the actual primitive
vertexes, and then we either clamp (for axis-aligned) or scissor (for non-axis-aligned)
to restrict the footprint to within the target-space sub-rect.

This then allows the use of a SWGL fast-path for the axis-aligned case that can vastly
speed up the common-case.

Comment 2

[Lee Salzman [:lsalzman]]

Attachment: Bug 1682195 - Ensure that area outside image mask is cleared if it is first clip. r?gw,nical

This fixes a previous bug in the image mask code that the tile rect caused cs_clip_image
to use discard on a first clip, the outside area would be left to whatever the initial value
of the texture from texture cache was. Since we need to support trimming down to the tile
rect for tiled image masks, this opts to just clear the background of the task in tricky
cases.

Depends on D111316

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b641b7f90108
Use scissoring to restrict cs_clip_image rather than discard. r=gw
https://hg.mozilla.org/integration/autoland/rev/f3b8d237e29a
Ensure that area outside image mask is cleared if it is first clip. r=gw

Comment 4

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/b641b7f90108
https://hg.mozilla.org/mozilla-central/rev/f3b8d237e29a

Comment 7

[Pascal Chevrel:pascalc]

Lee, this bug already created 6 regressions since its landing, instead of uplifting all the fixes from 90, should we back this bug out in 89 beta as this was an S4?

Comment 8

[Lee Salzman [:lsalzman]]

(In reply to Pascal Chevrel:pascalc from comment #7)

Lee, this bug already created 6 regressions since its landing, instead of uplifting all the fixes from 90, should we back this bug out in 89 beta as this was an S4?

2 were already resolved with fixes in 89, and 1 was a dup. This patch also helps fix a bug that was pre-existing before 89. That just leaves 3 uplifts to fix some regressions related to 3D transforms corner-cases. I think I would rather uplift those 3 fixes to 89.

I've requested the uplifts early enough in the beta cycle, and given that we are having an extended beta, I think I will comfortably be able to deal with any remaining unforeseen issues.