2019 Toronto Friday
(kvark, matt)
Basic order of operations on a stacking context is the following:
- gather all the children into a "surface"
- apply filters, e.g. opacity
- transform
Current handling of backface-visibility is not fully correct in WR, since we treat backface visibility in relation to the parent SC.
If Preserve3D is enabled, there is no "surface" to flatten/bake into, so we evaluate the ordering and backface visibility in the parent coordinate system. Opacity overrides Preserve3D, so there is no conflict of where the surface is considered.
Rules of backface-visibility evaluation are the following:
- if self has a transform (in non-preserve-3D context), this is what we evaluate visibility for
- if parent has Preserve3D, we evaluate visibility in the parent context
(kvark, gw)
Bugzilla page runs badly, we could identify 2 major issues:
- GPU utilization reaches 10ms and suffers from B_Image and B_Clip items. Could be explain simply by the memory bandwidth and bad utilization of L2/L3 caches.
- CPU staggers to process 200-450 draw calls. Upon further inspection it turns out that we break the batches because of the blend mode, which (for the platforms that don't support dual-source blending natively) depends on the color of the text.
One solution to the CPU issue would be adding the dual-source-blending extension to Angle, which Lee is looking into. Thre is another thing we could do: draw the text into an off-screen target with shader output pre-multiplied by the text color. Then we can draw all the text into the main target as "B_Image" with simple blending and no batch breaks.
TODO: prototype this solution
Another observation from Buzilla captured is the number of scissor changes (regions). We've seen cases where regions could be coalesced better than they are.
TODO: investigate why dirty regions are not aligned to tile boundaries