Bug 1607746 Comment 2 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

After some investigation, I believe the regression is due to changing the `flat varying mat3 vColorMat` to a `mat4`. This is inside the `brush_blend.glsl` shader which is used for all CSS filters and is also used for handling opacity in some cases. The change from `mat3` to `mat4` adds a performance penalty for all effects going through this shader.

In the case of the `sessionrestore` test, the only time the brush_blend shader is used is for opacity effects.

If a stacking context has an opacity of < 1, we manually add an opacity filter op here:
https://searchfox.org/mozilla-central/rev/d4d6f81e0ab479cde192453bae83d5e3edfb39d6/gfx/webrender_bindings/src/bindings.rs#2387-2409

The opacity filter goes through the brush_blend shader which has quite a bit of branching and a lot of logic for handling various filters. It would probably make sense to handle opacity on a stacking context in a different way than sending it through the filter path.

I don't really see a way to fix this regression without backing out the changes from bug 1606742 or giving stacking context opacity its own faster path.
After some investigation, I believe the regression is due to changing the `flat varying mat3 vColorMat` to a `mat4`. This is inside the `brush_blend.glsl` shader which is used for all CSS filters and is also used for handling opacity in some cases. The change from `mat3` to `mat4` adds a performance penalty for all effects going through this shader.

In the case of the `sessionrestore` test, the only time the brush_blend shader is used is for opacity effects.

If a stacking context has an opacity of < 1, we manually add an opacity filter op here:
https://searchfox.org/mozilla-central/rev/d4d6f81e0ab479cde192453bae83d5e3edfb39d6/gfx/webrender_bindings/src/bindings.rs#2387-2409

The opacity filter goes through the brush_blend shader which has quite a bit of branching and a lot of logic for handling various filters. It would probably make sense to handle opacity on a stacking context in a different way than sending it through the filter path.

I don't really see a way to fix this regression without backing out the changes from bug 1606742 or giving stacking context opacity its own faster path. Any thoughts?

Back to Bug 1607746 Comment 2