wrote a quick post about the problems I've experienced with wasm gc and realtime graphics https://dthompson.us/posts/wasm-gc-isnt-ready-for-realtime-graphics.html
one mistake I made is that saying wasm GC is wonderful wasn't enough to keep the anti GC crowd from saying that no GC managed runtime can do realtime graphics, which is total bullshit btw!
@dthompson damn, that's unfortunate :/
@daviwil yeah, I've known about these issues for awhile but many people aren't aware so it seems good that I wrote about it. have had enough people ask me about webgl on hoot to make it feel worth the time.
@dthompson I was wondering if there was a way to access the linear memory with Hoot. Do you happen to know if it is possible?
@gugurumbe not part of the public interface. hoot's implementation uses a memory object as stack space for unboxed values, though.
@dthompson the scratch space option sounds a bit like the bytearray trick you use in Guile+SDL code to avoid GC pressure.
(or did I get that wrong?)
@ArneBab on guile you can access the contents of a foreign pointer as a bytevector directly, no copy required.
@dthompson so it’s more similar to batching in Chickadee where you prepare images that are then only referenced, cropped and moved?
@ArneBab batching is for the geometry not the image data and that's useful for lots of data that changes every frame. Batching would be very painful to do with wasm GC right now due to the problems mentioned in the blog post. These problems don't exist in Guile.
@dthompson Then I misunderstood what you meant with the scratch space. Isn’t that something where you prepare data by pushing it through the wasm-gc/wasm-linar-space boundary?
@dthompson yeah that’s dumb because C# exists and lots of games have been made with c#