The compositor is evil

Created on 2022-09-04T21:29:51-05:00

Return to the Index

This card pertains to a resource available on the internet.

This card can also be read via Gemini.

Early real-time graphics systems operated under extremely constrained environments (low memory) at fast (~16ms/frame) speeds. Renderers had to exploit artifacts of hardware like fixed cycle counts of the processor and "racing the beam" where they write around video buffers while scanlines are still being emitted.

Apple's Quartz changed from direct pixel access to drawing on canvases which were then composed in to a display via the compositor process.

Evolution of compositors where elements are drawn via CPU rendering to textures; textures are then subjected to effects/clipping/etc to create the full UI which may even be animated.

Window resizing can be difficult to implement in the OS because rendering contexts and window manager contexts are changing and need to be synchronized to avoid jank (when doing smooth window resize.)

Latency: even though a render+composite+flush cycle has a 16ms budget (60 FPS) a new rendering could be delayed by 2-3 frames depending on where the raster beam is at the time of the event.

Beam racing compositor: track damage rectangles, commit to current frame if beam has not caught up and defer to next frame if its too late.

Beam racing designs allow very fast response times but require tight control of the system. Jobs are not allowed to pre-empt the graphics processor.

Original view multiplexers

Not quite compositors; they coordinated events and drawing with multiple pieces of software but still essentially gave all control of drawing to the process.

Blit: a block copy based system by Rob Pike (and the origin of "bit blit.")

NeWS: a Postscript interpreter; programs created UIs by defining trees of postscript blocks which were rendered.