26-OCT-2025

1244

I had an idea last night that I think squares everything up. Instead of pulling images in and rendering ‘on-demand’, the renderer should instead run as an independent process that allows ‘subscribers’

The pipeline would then be for an internal model to update, which the renderer can observe; the renderer creates a new frame and sends a pointer to each subscriber, the UI is a subscriber. On application start, the model is booted, then the renderer, then the UI ‘subscribes’ to the renderer and passes the imageref to whatever widgets it likes.

Ideally it’s a queue, so the UI event loop runs, places the new image in the ‘right slot’, but only renders the actual UI every 1/f seconds (f = framerate), So if the renderer ends up generating 3 frames before the render call happens, it should only copy the image for the last of those frames, the rest just being an Arc/other ref to the image data. This also means the renderer can be ‘smart’ in the sense that I can create an SVG of the whole map, and dynamically grab portions of it after rendering it once. I can also have the renderer manage multiple layers and other tweaks by making the image reference a little smarter. This nets me the SVG-based approach I wanted (for transportability) and the speed I’m looking for (since the map should change pretty rarely).