Comment by magicalist

I highly suspect that the issue is that Windows video playback can only use scanout compositing if there is nothing on top of the video. Scanout compositing is significantly more energy-efficient than standard framebuffer compositing because it avoids a memory copy each frame.

This ultimately comes down to hardware limitations. GPUs are limited as to what they can compose during scanout, because of memory bandwidth limits. Each plane that you can alpha-blend together at scanout time multiplies the amount of memory fetches per dot you have to do. On today's high-DPI displays, the bandwidth going out to the display is very high to begin with, so you can't afford to multiply that by much. That is why putting something on top of a video is tricky: you're adding another layer to be alpha-blended on top, increasing your memory bandwidth by 50% over the two layers you already have (RGB for the background plus YUV for the video). The user's GPU may or may not support that--as I recall, prior to Skylake, Intel GPUs only had two hardware planes, for instance.

I'm not surprised that Microsoft just used "are there any DOM elements over the video?" as a quick heuristic to determine whether scanout compositing can be used. Remember that there is always a tradeoff between heuristics and performance. At the limit you could scan every pixel of each layer to see whether all of them are transparent and cull the layer if so, but that would be very expensive. You need heuristics of some kind to get good performance, and I can't blame Microsoft for using the DOM for that.

On the other hand, pretty easy how such a div might trigger a less efficient path; if the video is top in the z-order then it can probably bypass being composited by the browser (and who knows, maybe even bypass being composited by the OS) and avoid a whole mess of rendering to a texture, texturing some triangles, and so on and so forth.