Hacker News Reader

Comment by LeoNatan25 | Hacker News Reader

Hardware accelerated decoding is enabled even in windowed players. On Macs, especially when using QuickTime, the only difference between fullscreen and “windowed” windows is the size of the surface and the hidden Dock and menu windows.

View on HN

Full screen video could skip most of the other composition that needs to happen, though. So while the video decoding itself may not be any different, it certainly won't have to go through drawing everything else that would otherwise be on the screen.

Edit: as the sibling noted too, they could also de-prioritize other apps since presumably you're not really using them.

Yes, that is what I said in this thread in the first place; in fullscreen, the window manager needs only draw the player window.

I wouldn't be surprised if the trick is the resolution it is decoding to. Could test this by picking windows that are a related size to full screen.

Could also have something that just gives the movie larger slices of computer time and clock down, if in full screen.

That makes little sense. When decoding to fullscreen canvas, on a retina display, the 1080p video needs to be rescaled from 1920x1080 to the retina resolution, whereas in windowed, it is 1:1 pixel mapped (in the case of QuickTime X).

I was expecting they optimised there. I was also just throwing up ideas. :)

I assumed convenient sized windows for the viewer, not native res ones.

Actually the size does not really matter, since the scaling will be done in hardware on the GPU if possible, and scaling in hardware (or shaders) is not a very intense task.

For video playback you have a first step on the GPU, which is decoding the video (e.g. from h.264 into uncompressed video). You can from there go several ways, e.g. read the video back into main memory, do post-processing on the CPU and somewhere blit it back on a surface. This is not really what one wants for good performance. Instead of that all necessary post-processing (including scaling and other things like color-space conversion) can also be directly done on the GPU after decompression. Again, after that step the output can be read back or it can be directly forwarded towards the video output. For the best performance you go all-the-way on the GPU. This works in fullscreen mode as well as in windowed mode (you can instruct the GPU to use only a part of the screen for the video).

I had some task in the last year where I had to use gstreamer for video rendering, and using various configurations I could see their impact quite good. E.g. CPU-based postprocessing (through the videoconvert pipeline plugin) was very slow compared to the GPU hardware-based one (vaapi) on the Intel Atom box.

Again, I was mainly throwing ideas out. But you are also conflating "does not" with "should not." Clearly something is different. What?

Desktop composition.

There are many possible reasons for the the lower power consumption. E.g. the OS could schedule processes other than the foreground window less often in fullscreen mode. Or it even detects that the user watches video and puts the CPU in a very low power (low frequency) mode. Or it's the overhead of the desktop environment and compositor. I have no idea.

I justed wanted to give an explanation why I don't think that the video scaling makes a huge difference.

And that makes perfect sense. These are all hypotheses to be ruled out, at this point though. Indeed, your "schedule processes" one is essentially the other idea I threw at the beginning. My hunch is more likely that is the deal. I'd have to eliminate both through testing, not reasoning, though. Reason can not and will not ever eliminate why something behaves against expectations.

I remember being amazed the first time you could have a Quicktime player window playing live video and also being slow genie-effected to the dock if you held down the shift key as you minimised the window.

Yes!

Reply on news.ycombinator.com