They still use "overlays" - just they're a lot more featureful in modern implementations than "Replace all of one colour with another surface" - so they tend no

They still use "overlays" - just they're a lot more featureful in modern implementations than "Replace all of one colour with another surface" - so they tend not to have the same limitations and quirks. MS started exposing some capabilities using MPO in the windows 8 era [0], and they've pretty much always had pretty comprehensive composition pipes in hardware for mobile platforms due to the power/bandwidth limitations meaning compositing the display can be a significant fraction of the total device's performance. I suspect green (or other block colour) artifacts on video edges are due to bugs/mismatches in specification with the hardware video decoder and how the app displays it, and the bugs that often fall out of that. Most video compression requires pretty large blocks, normally from 16x16 up 64x64 depending on format, and that may not align with the actual video size (e.g. 1080 does not divide by either). But often implementations still need that extra surface, as things like motion vectors may still refer to data in the "invisible" portion. And it has to be filled with something. It's then real easy to fall into bugs where small numeric errors in things like blending, or even just mix-ups between the different "sizes" that surface has, to cause issues at the edges. I suspect the other comment about using ANGLE/dx9/dx11-on-12 may be effective as it /also/ causes the hardware video decoder not to be used, which is often a source of "unexpected" differences or limitations that commonly cause errors like that. [0] https://learn.microsoft.com/en-us/windows-hardware/drivers/display/multiplane-overlay-support https://learn.microsoft.com/en-us/windows-hardware/drivers/d...