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..
Still need a spacial indexing method to prevent redundant enqueues to the drawlist (esp for text)
I'm in the process of trying to see if I can keep getting vefontcache even more performant... Making it multi-threaded can help but there might be some single-thread per still possible..
* 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...
ed