Anything considered static can be aggregated into a single VArena. We don't have to worry about ever releasing its memory or it growing "too large". All memory here must be fixed sized.
Conservative persistent memory can grow on demand but we would perfer if it could be trimmed or released when no longer dealing with heavy scenarios. Persistent memory should use a slab allocator that is backed by a virtual address space pool allocator instead of pools allocating from a single varena. Chained Arenas can source thier chunks of vmem from the slab which can be utilized for scratch memory. Fonts should be loaded from VSlab. The string cache should use a dedicated varena with 16-byte alignment. All conservative memory should be trimmable by a wipe command which should free all unused blocks. Each block should be a single OS aware reserve of vmem.
The Frame can possilby stay as a single varena with scratch allocation utilized on demand. Although it may be more viable for chained varenas to be derived from the main varena via a slab or pool interface. Frame memory should be trimmable on command which should release its committed vmem to its initial value. A dedicated transient varena should not exist. It should be removed when possible. File mappings for now can use a dedicated varena made on demand with a capped reserve size of 4 meg. Any file exceeding this needs the host to support virtual memory mapped I/O for files. The codebase db will use sqlite for the file I/O abstraction.
Host might only need to track the first persistent block of vmem, and the rest can be handled by the client (including wrapping that vmem up in a varena). Hot-reload only needs persistent vmem's ref restored on the client module's side. All other references can be resolved from there.
* Add back proper batching (busted the rendering for it though..)
* Some reogonzation of definitions and procedure args
* CURRENTLY BROKEN: Something went wrong with the calculations for text positioning..
* draw_text_string_pos_extent_zoomed can now oversample text futher (if desired)
* render_ui_via_box_tree has a rudimentary render pass layering optimization
Add support for the slab allocator to accept arbitrary alignments (odin's map container needs it)
Messing around with 64-byte alignment as the default for the allocator...
Still need to figure out input event consumption, I don't want to do it with the event ring.
I would like to setup input binding layers and then have the push/pop input contextes with a set of bindings.
If the bindings are detected it should "consume" that binding from further use for the buffered time period.
This will be really important with how heavily model this app will be.I
HMapChained causes memory corruption in VEFontCache (not sure why yet), so I switched temporarily over to HMapZPL.
Fixed bug with parser_get_glyph_shape from me tracking vertices as u16s instead of i16s.
Currently a bug with the frametime example:
text_test_str := str_fmt("frametime: %0.2f", frametime_avg_ms)
It doesn't handle per-frame updates properly compared to C++ source
I'm enforcing aprintf it as the default formatter.
I changed up the context allocator assignment to reflect how I've been intending to allocation in startup & platform events vs tick.
Tick uses the frame slab's by default with transient on temp. Startup & platform events use the transient by default & for temp, with any use of the persistent allocator being explicit.
