It almost certainly has to do with the desktop window compositor.
When you have a video playing within a web browser window, and worse than that, in a plugin, the web browser has to render its page thusly:
- Draw our window decorations (address bar, bookmarks, buttons, etc.)
- Draw the first parts of the webpage.
- Draw a "black square" where the video is supposed to be, but draw the relevant parts of the webpage on both sides of it (left and right).
- Ask the plugin nicely to draw in the place it said it wants to have its window in.
- Draw the rest of the webpage beneath the window, down to the bottom of the page.
- On top of this sequence, the compositing window manager, which is responsible for the animated effects (like when you minimize and maximize windows, etc), has to keep track of the contents of every window on the screen. As part of this, it has to keep track of everything drawing inside that window, including the plugin, which in Chrome is an out-of-process plugin (meaning, it's part of another process, not the chrome main process). If the compositing window manager didn't keep track of this, and treat everything in the window as a "3D texture", it wouldn't be able to animate the minimization of a window into your taskbar when you click the minus button.
When you tell Flash (or Silverlight) to play the video full screen, what happens is that Flash stops telling Chrome to render anything. In fact, the entire compositing window manager can be temporarily disabled, and every other program that might be responsible for rendering graphics to the monitor is temporarily told to stop rendering (or, perhaps, they are allowed to submit drawing commands, but they have no actual effect on the screen.)
Graphics pipeline while not full-screen:
Browser and Flash/Silverlight -> compositing window manager -> graphics hardware
Graphics pipeline while full-screen:
Flash/Silverlight -> graphics hardware
This simplified pipeline reduces overhead because there is less buffer "copying" going on, and the entire video processing looks something like this:
- Download the video content from the network.
- Decrypt the video using the DRM system.
- Use a special part of the GPU, called the fixed-function video decoding pipeline, to perform hardware decoding of the video data to an uncompressed format.
- The hardware video decoding pipeline can now copy the decoded video straight into the graphics framebuffer and play it -- without sending it back to the CPU/RAM!
The fans spin up and more power is eaten when the video is windowed precisely because the compositing window manager is always saying, "OK, what does the video look like right now?" and it has to be read back into the CPU (and probably buffered in RAM) before the compositing window manager then decides to write it right back out to the graphics card, along with all the other composited data (the browser, the taskbar, etc.)
The compositing window manager has to keep asking for the video content to be transferred back to the CPU because, under normal circumstances, the only process on the system that is allowed to write directly to the video framebuffer is the compositing window manager. The browser, the video player, and every other component on the system has to go through the compositing window manager, like a gatekeeper or spokesperson, which sits between the hardware and the user space.
This is partly to enable "effects", and partly for security and stability reasons, because programs are unable to directly corrupt the desktop (either maliciously or by bad coding); the compositing window manager won't let it. But then, when the compositing window manager is disabled (at the request of privileged programs such as Flash and Silverlight), suddenly that extra layer of "overhead" is gone.
The compositing window manager used on Mac OS X is called Quartz Compositor and it has been a part of OS X for a long time. Quartz Extreme is the modern incarnation of the Quartz compositor, which does everything I described above on the GPU itself (although these operations aren't "free" just because they're offloaded to the GPU; the GPU still consumes power performing these compositing steps.)
For a developer perspective of exactly how a program (such as Flash, or Silverlight) can take full screen control and temporarily disable the Quartz Compositor, see this Apple developer doc.
Long story short: Quartz Compositor + very frequent screen updates (30 to 60 times per second with video) == high CPU usage. Remove the Quartz Compositor component from the pipeline and CPU usage drops dramatically, especially because Flash and Silverlight have hardware-accelerated video rendering and video decoding.
