20-OCT-2025

1352

I don’t know that it fixed it, but it is slightly less laggy now. I need to hook up console or something to get data out, but I think the issue is that svg is fundamentally going to be slow because it’s just a long, unaccelerated pipeline and ultimately it’s not even really necessary; I could just work directly on the image buffer.

The upside of svg is that it is lightweight for a render-once-clientside application, which isn’t my intent; and it’s nice to convert to other image formats and resolutions. The downside is that it is unlikely that I’ll ever be able to render it quickly enough to ‘work’. I think next step is to start sticking probes around it and seeing if I can get some timing data out, I suspect it will quickly show more blocking processes that need to be handled; and it will also probably show that each of those blocking processes still take a long time to render. Low framerates for the thing are tolerable, but dismal ones won’t be, so I might still go for a ‘render via ratatui-image’ approach, but just manage a DynamicImage (or some wrapping structure) which I copy out when rendering each frame. Then I can have a process continually buffer a new frame and just asynchronously ask for the current one each actual rendered frame. Should be significantly simpler and avoids me having to write a template file.

1425

I hooked up tokio_console and found some interesting info. In particular there are, as expected, quite a few blocking functions. In particular there seem to be 4 copies of the render step running all the time, Only one task seems to ever actually be running; which shouldn’t be the case, and because of this I seem to remain pretty far down in the queue. I think tokio is basically shoving blocking tasks onto threads, those tasks take a while to return so it creates another one w/o cancelling the first, and so it quickly exhausts all it’s available worker threads and spins waiting for all it’s stuff to finish. Trying to feed people in half the time by cooking twice as much food.

It seems that the problem ‘should’ be solved with messages, as I had been moving towards before. Sending a message can be ignored if the render is already in progress, so you just have a little state machine on the far side and if it’s rendering, it adds another return address to the queue.

I want to benchmark the actual SVG rendering time for a reasonably complicated SVG, so I think I’m going to create a separate map renderer that doesn’t do any of the ratatui stuff, then I can figure out a best-possible render time; if that is acceptable, then I like the idea of trying to keep the SVG-based approach since being able to keep the actual content of the game in pure xml/text seems nice from a longevity point of view. Easy to store and compress, easy to build another interpreter for, etc. If it’s not, then using image and writing a simple rasterizer (I think that’s the right term, a thing that takes abstract model of space and turns it into pixels is what I mean, I’m not a graphics guy) should be the path, since I’ll have all the control I can manage and can make the pipeline async-throughout, which would hopefully resolve the issue as well. In any case I think it’s a good opportunity to use the state-machine port.