Zero-copy claims are likely exaggerated

[MostAwesomeDude]

Hi! I wanted to help dispel a couple misconceptions that I see here and in the associated Reddit thread.

In general, rendering to screens is not zero-copy. There are several moments where a copy is inevitable for an image-gallery application regardless of how images are packed on disk.

• The most important copy is to VRAM. Because framebuffers are scanned out near their corresponding physical connectors, and displays usually are driven in units like gigabytes/second, this copy is presumed to be DMA. This copy is the same one which occurs when rebinding textures in GL.
• The image formats that you've discussed include JPEG and PNG. JPEG doesn't have pixel data, so it can't be directly mapped to a pixel buffer. PNG is internally compressed with zlib, RLE, and often with interpolation as well; it almost never can be mapped to a pixel buffer, and certainly not after using optipng or pngcrush on it.
• VRAM-to-VRAM copying is usually faster than reusing buffers when the GPU is used for image decoding. Any time a VRAM object is reused in a new context, like turning a drawbuffer into a texture, the driver must rebind all dependent objects and issue memory fences to the GPU's command buffer. Paradoxically, this means that it might be faster to use extra VRAM and make an extra copy of the pixels so that the copy can be immediately used in the following draw command.

This all arises when drawing video frames, which is a low-latency fixed-deadline situation that demands an efficient codec. Note that GPU-friendly codecs do not do all of their work in VRAM; instead, some of their coding is inherently serial and maps fairly well to SIMD instructions on the host CPU. This is a final irony: instead of DMA, the format is designed to be read from disk through the CPU to VRAM.

[ef1500]

Thanks. I've learned a lot in the past 24 hours that I didn't know beforehand.

I'm making revisions to the README, so please do let me know if I've overstepped anywhere else.