Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The term "framebuffer" is a bit overloaded here. In this case it means basically "monitor scan out buffer" and is therefore a very special, particular thing. In most other contexts 'framebuffer' usually just means your color output buffer, which is just a buffer of some kind, sitting in some RAM somewhere, with otherwise no special meaning.

When you setup a swap chain for GUI rendering, for example, you're just doing a glorified malloc call. It's not coupled to a hardware port. It's not really even all that special. And then like any other color buffer, you can use that color buffer in other ways, writing it to yet other color buffers.

All that said the display output pipeline itself still is more sophisticated than this. Not necessarily by all that much, but it is. Particularly in that there's not necessarily "one" buffer that drives the monitor. There's this idea that composition can happen "on the fly" during scan-out by dedicated hardware, which are done via multiple planes. How many planes can be used then depends on the hardware, but for example most Android phones have 4-8 hardware planes. Desktop hardware tends to have fewer such overlay planes (the power efficiency gains don't tend to matter much when you have infinite power), but modern Intel integrated GPUs I believe have 3 planes. This is particularly useful as one of those planes is for video. This means that when you're watching a video, if things are working properly, then the GPU can be basically powered off entirely.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: