18-AUG-2025

0921

The process for rendering a hexfield is going to involve the following parts:

  1. Map from image dimensions (which I should look up on load and store in the cache) to nominal hex dimensions, scaling everything to the same scale. This’ll require some math to determine the anchor points in the SVG for the image

  2. Figure out the viewbox/viewport/svg size stuff. This might be just ensuring I’m not working near the SVG origin (since I think negative x/y values are not supported? Not sure. Might be able to solve this by making matching adjustments to the viewport offset when I select subsections). - Indeed, my example images have a big pile of surrounding transparency, the hexes are centered, though, so it should be easy enough to find the center dynamically. which should allow placement relative to the center, it is absolutely top-left anchored atm (by experimentation). - This may also explain why the fill wasn’t working, it was, we were just only seeing the transparent section. I’ll need to experiment to see if adding back the defs saves time once there are a lot of hexes being shown. - an upshot might be that I could make a texture to apply to the hex, instead of a hex image; contiguous regions of hexes could pull from coordinated parts of the texture and get semi-random changes to add variety.

  3. Use existing hex math stuff to place all the hexes, this will probably need some more math to go from nominal hexes in radial space to the image dimensions which will be weird.

Before any of that I have to make this shit async because it is so annoying to wait for the thing. It’d also be good to get it to automatically rerender every few seconds or whatever.

1024

Looking at the async stuff, it may be that I need to separate the drawing side of the SVG stuff and the display. The widget can have an async ‘update’ function which stores the pngdata in the struct, the render just splats the pngdata to the screen.

1113

I started to tease apart the update/render parts of the svg so I can async it. The picker part is a little tricky to locate, and I’ve got a lot of state that needs managing, but I think I should be able to pass through the picker information (perhaps as part of the state for SVG?).

It feels like there should be a trait for ‘Async’ widgets (similar to stateful widgets), which are widgets with state that endure a separate update loop. Each would get all the current layout information, so that, for instance, I can pre-render the next SVG frame to the correct size, but one would get called to manage FPS and the other for actual state upate?

IDK, feels like there’s a pattern here, haven’t found it yet.

I definitely think the layout should get cached, maybe I just don’t like immediate-mode UI? :) It’s just a set of rects that get calculated, it’s another thing that I could stick in an async update loop and reference everywhere.

One crazy idea here would be to refactor so the whole UI is done as an SVG. At that point I’m just sort of streaming graphics over the terminal protocol so it’s a little bit silly, but I suppose that’s probably what, e.g., canvas is doing in a browser over HTTP.

1319

I think I’m moving inexorably towards an event-loop style system with a bunch of asynchronous handlers with a framerate-managed render loop. The current method does a loop like:

1. Check for exit
2. No exit, then handle events (sync)
3. Update (async)
4. synchronize
5. Draw

What would be ideal is if the startup ran two systems, the frontend UI which just does the draw step on a fixed-framerate-target loop, and a ‘backend’ component which is asynchronous. The frontend would capture events and send them to the backend, and request data from the backend when needed to render.