> GPUs can actually scan to a display from multiple framebuffers in different resolutions and color formats in the same time.

This is also how early SLI worked: each GPU has a framebuffer, one holding the "even" scanlines and one holding the "odd" scanlines. Each GPU does its own rendering work to its own framebuffer, each rendering a vertically-squashed scene, with one scene offset by one pixel vertically. The master GPU then interleaves the two framebuffers together (pulling data from the slave GPU's framebuffer over the SLI link) when outputting a field.

To add to that, "early SLI" stands for Scan-Line Interleave, not Scalable Link Interface like it is now. CRT was some crazy shit to deal with. I'm glad I never had to deal with it.

If you ever wondered why some old Youtube video looked like crap and has lines that don't match up, interleaving was why.

Usually artifacts are not the result of using interleaved source but the result of recoding done wrong. I remember reading mencoder manual about "pulldown" and other recoding options.

Eh, it's a handy abstraction. There's also no uniform memory space (multiple RAM chips, virtual memory, swap), CPUs absolutely are not the "run one opcode after another" thing that programmers pretend, and by the time you stream HTML from a server to client it's been sliced into a thousand pieces, compressed, encrypted, reordered...

We like abstractions.

Windows used a separate buffer for mouse cursor and video overlay. Seems like a good idea that helps to achieve smooth GUI performance even on a slow machine. You don't have to calculate what part of video frame is covered by other windows and you don't have to update pixels when moving a mouse cursor.

Yup, on Android this is handled by a service called SurfaceFlinger which you can easily inspect from the shell(adb shell dumpsys SurfaceFlinger).

Not sure if it's still the case but back in the ICS days your status bar, wallpaper and launcher/app were all separate surfaces that were scanned out from different frame buffers.