brush rendering is now completely client-side.
the server only receives edits the client would like to do, in the form of PNG images of chunks, that are then composited onto the wall
known issue: it is possible to brush up against the current 256 chunk edit limit pretty easily.
I'm not sure it can be solved very easily though. the perfect solution would involve splitting up the interaction into multiple edits, and I tried to do that, but there's a noticable stutter for some reason that I haven't managed to track down yet.
so it'll be kinda crap for the time being.
unloading is done together with the autosave process, because it's the most natural place to do it.
since we literally just wrote to the database and can easily check if the chunk hasn't been written to since.
- reducing the waterfall for JavaScript
- making the throbber appear properly if not all CSS is loaded; fonts.css and index.css are made non render-blocking
the goal is to rewrite haku completely, starting with the VM---because it was the most obvious point of improvement
the reason is because Rust is kinda too verbose for low level stuff like this. compare the line numbers between haku1 and haku2's VM and how verbose those lines are, and it's kind of an insane difference
it also feels like Zig's compilation model can work better for small wasm binary sizes
and of course, I also just wanted an excuse to try out Zig :3
what was happening is we were setting style.width and style.height which overrode the styles from CSS that gave us the BoundingClientRect from which we were calculating the canvas size
I also added a sendViewportUpdate to prevent chunk jank
it looks like this:
- 3200% +
I'm giving up on the 100% zoom button from the original idea, because rkgk's scaling curve makes it easy to go back to 100% if you need to.
the main canvas is now DPI-aware; it should no longer be pixelated on 4k
this couldn't be done for the brush preview, so it's just kinda pixelated
also fixed the horrendous scrollbar that could appear on HiDPI for some reason
