Update

double_buffering.md

@@ -12,4 +12,4 @@ There also exists [triple buffering](triple_buffering.md) which uses yet another
 
 Double buffering can be made more efficient by so called page flipping, i.e. allowing to switch the back and front buffer without having to physically copy the data, i.e. by simply changing the [pointer](pointer.md) of a display buffer. This has to be somehow supported by hardware.
 
-**When do we actually need double buffering?** Not always, we can avoid it or suppress its memory requirements if we need to -- we may want to do this e.g. in [embedded](embedded.md) programming where we want to save every byte of RAM. The mainstream computers nowadays simply always run on a very fast FPS and keep redrawing the screen even if the image doesn't change, but if you write a program that only occasionally changes what's on the screen (e.g. an e-book reader), you may simply leave out double buffering and actually render to the front buffer once the screen needs to change, the user probably won't notice any flicker during a single quick frame redraw. You also don't need double buffering if you're able to compute the final pixel color right away, for example with [ray tracing](ray_tracing.md) you don't need any double buffering, unless of course you're doing some complex [postprocessing](postprocessing.md). Double buffering is only needed if we compute a pixel color but that color may still change before the frame is finished. You may also only use a partial double buffer if that is possible (which may not be always): you can e.g. split the screen into 16 regions and render region by region, using only a 1/16th size double buffer. Using a [palette](palette.md) can also make the back buffer smaller: if we use e.g. a 256 color palette, we only need 1 byte for every pixel of the back buffer instead of some 3 bytes for full [RGB](rgb.md). The same goes for using a smaller resolution that is the actual native resolution of the screen.
+**When do we actually need double buffering?** Not always, we can avoid it or suppress its memory requirements if we need to, e.g. with so called **[frameless rendering](frameless.md)** -- we may want to do this e.g. in [embedded](embedded.md) programming where we want to save every byte of RAM. The mainstream computers nowadays simply always run on a very fast FPS and keep redrawing the screen even if the image doesn't change, but if you write a program that only occasionally changes what's on the screen (e.g. an e-book reader), you may simply leave out double buffering and actually render to the front buffer once the screen needs to change, the user probably won't notice any flicker during a single quick frame redraw. You also don't need double buffering if you're able to compute the final pixel color right away, for example with [ray tracing](ray_tracing.md) you don't need any double buffering, unless of course you're doing some complex [postprocessing](postprocessing.md). Double buffering is only needed if we compute a pixel color but that color may still change before the frame is finished. You may also only use a partial double buffer if that is possible (which may not be always): you can e.g. split the screen into 16 regions and render region by region, using only a 1/16th size double buffer. Using a [palette](palette.md) can also make the back buffer smaller: if we use e.g. a 256 color palette, we only need 1 byte for every pixel of the back buffer instead of some 3 bytes for full [RGB](rgb.md). The same goes for using a smaller resolution that is the actual native resolution of the screen.