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.
> You need heuristics of some kind to get good performance, and I can't blame Microsoft for using the DOM for that.
which, again, that's fine, but mayyyyybe they were a little lax in checking performance on nearly any other popular video site on the web to see if that heuristic is a good one?
Or maybe changing page layout in an extremely common way wasn't an effort to undermine a hyper specific benchmark?
I'd assume that it was actually an invisible, but not technically hidden div, leading to a fully transparent blending pass - divs with opacity:0 or display:none are trivial to optimize for this case.
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.
FWIW, I think you're a little credulous there; as I mentioned in my other comment[1], I can't find anything stating that Chrome starting beating Edge at the test (their videos actually claim the opposite) or anybody from Chrome boasting about it (articles from the time like yours[2] also say the opposite).
> On the other hand, pretty easy how such a div might trigger a less efficient path
I mean, sure, you can always fall off the fast path, but given how common transparent divs over video are, the battery benchmark should have come with even more caveats. Edge is the most battery efficient browser†!
† for playing fullscreen video††
†† Battery test not valid if the page doesn't use the exact layout youtube used in December 2017. Also not valid if testing vimeo, or twitch, or any porn site, or...
> it's doing something that lacks any real reason but which hurts Edge.
In my own web development activities I can point to hundreds upon hundreds of hidden, invisible, and obscured DOM elements that have no obvious reason to for existing to someone outside the code-base where you find the commen explaining the required work around, browser hack, or legacy constraint. I've also experienced wildly divergent performance on MS browsers compared to others when creating content, often from something as trivial as DOM order or composition.
Clearly Google owes me some money for my part in their ongoing conspiracy to hurt Edge. I'm flexible, I'll accept GCE credit :)
> it's doing something that lacks any real reason but which hurts
Hey, there's a new div in the DOM, the only possible reason for a change like that is so Chrome can advertise about beating Edge on a benchmark nobody cares about? Even though they never beat Edge on it and this "advertising" never took place?
This was the credulity I was talking about. These events didn't happen (you literally wrote the stories plural! about edge winning the benchmark) and the motivations make no sense. I'm not sure why you'd repeat it without even a warning that it may just be a narrative made up from grumblings about fixing a fast path heard third hand.
I do care about video playback battery performance.
So much so, in fact, that I bought my current laptop specifically so it would last long when watching videos.
Also note that tablets, smartphones, the Macbook Air and the Surface are sold on their battery stamina, and specifically while watching videos. And how would you measure that? Youtube, of course!
I fail to understand how an empty DIV can break a state-of-the-art video acceleration. Why not add another check to remove such empty HTML tags before hand.
> Why not add another check to remove such empty HTML tags before hand.
Sure, and they did. And then next month it’ll be something else, and a new check. The next month it’ll be something else yet again, and yet another check. Pretty soon Microsoft’s codebase is littered with checks and guards against the random things Google does, and they’ll still always be a deploy behind. Google could keep this up for years.
I'd suggest inspecting a few sites you watch video on. An empty div is the least weird thing you'll find.