To keep code size small and constraining development of ctx from the beginning has been the ability to use it for antialiased resolution independent user interfaces on microcontrollers; the first prototyping board was card10. If you have your own retained scene-graph/widget tree, or use immediate-mode-gui approaches; ctx can be used to render the scene in chunks/scanlines permitting larger displays to be driven from microcontrollers. With more RAM at disposal and some subtexture update capable LCD/OLED displays and eink, using the drawlist for storing drawing commands becomes possible - as well as the hash-caching capability to reduce inter-frame redraw and recomputations.
The performance of ctx has increased since these video were made, and making more use of RGBA8 directly in small bands is preferable to working in RGB565 like these demos did. New iterations of demos are planned, and the codesize of ctx with full HTML5 canvas API support fits modern microcontrollers, the codesize can be as small as 28kb + 20kb (ascii font) of footprint and needing as little as 5kb at runtime. (Addendum 2024) a really minimal build in terms of code size has not been done in a while and ctx currently clocks in at 64-128kb for a small build; RAM requirements remain small.
The arm-cortex-m4 at 97mhz in the card10 badge and on the TTGO ESP32 both with immediate rendering, the card10 has a 180x80 display with really high visual quality, while the TFT LCD on the ESP32 has slightly higher pixel resolution at 160x128, video from november 2019. Usage of ctx for rendering the existing graphics API but with antialiasing has landed in card10, the following camp badges flow3r and tildagon- had a ctx renderers when hardware was publicly available.