diff --git a/code/grime/linked_list.odin b/code/grime/linked_list.odin index 5c2b993..fa17d37 100644 --- a/code/grime/linked_list.odin +++ b/code/grime/linked_list.odin @@ -5,20 +5,20 @@ An intersive singly & double linked list implementation */ package grime -LL_Node :: struct ( $ Type : typeid ) { - next : ^Type, +SLL_Node :: struct ($Type: typeid) { + next: ^Type, } // ll_push :: proc( list_ptr : ^(^ ($ Type)), node : ^Type ) { -ll_push :: #force_inline proc "contextless" ( list_ptr : ^(^ ($ Type)), node : ^Type ) { - list : ^Type = (list_ptr^) - node.next = list - (list_ptr^) = node +sll_push :: #force_inline proc "contextless" ( list_ptr : ^(^ ($ Type)), node : ^Type, node_next: ^(^Type) ) { + list: = (list_ptr ^) + (node_next ^) = list + (list_ptr ^) = node } -ll_pop :: #force_inline proc "contextless" ( list_ptr : ^(^ ($ Type)) ) -> ( node : ^Type ) { - list : ^Type = (list_ptr^) - (list_ptr^) = list.next +sll_pop :: #force_inline proc "contextless" ( list_ptr: ^(^ ($ Type)), list_next: ^(^Type) ) -> ( node : ^Type ) { + list : ^Type = (list_ptr ^) + (list_ptr ^) = (list_next ^) return list } diff --git a/code/grime/pool_allocator.odin b/code/grime/pool_allocator.odin index e760911..8a51aa2 100644 --- a/code/grime/pool_allocator.odin +++ b/code/grime/pool_allocator.odin @@ -353,7 +353,7 @@ pool_validate_ownership :: proc( using self : Pool, block : [] byte ) -> b32 { misalignment := (block_address - start) % uintptr(block_size) if misalignment != 0 { - // TODO(Ed): We cannot use thsi to validate that the data is within the pool bucket as we can provide the user different alignments + // TODO(Ed): We cannot use this to validate that the data is within the pool bucket as we can provide the user different alignments // ensure(false, "pool_validate_ownership: This data is within this pool's buckets, however its not aligned to the start of a block") // log(str_fmt("Block address: %p Misalignment: %p closest: %p", // transmute(rawptr)block_address, diff --git a/code/sectr/app/state.odin b/code/sectr/app/state.odin index 9d0f201..a2ccc83 100644 --- a/code/sectr/app/state.odin +++ b/code/sectr/app/state.odin @@ -63,11 +63,16 @@ frame_allocator :: proc() -> Allocator { return result } +// TODO(Ed): Rethink usage of transient arena +// We can have it so that all usage of transients are chained 64 mb arenas. The users can clear the scratch and make a free-list on the parent varena. +// Anything over 64 mb or the chaining threshold should really have dedicated memory. transient_allocator :: proc() -> Allocator { result := varena_allocator( Memory_App.transient ) return result } +// TODO(Ed): This needs to be reviewed as we technically can keep the whole file in buffer, +// but are we better off with a storage virtual mapping on-demand requested from the host by the client? files_buffer_allocator :: proc() -> Allocator { result := varena_allocator( Memory_App.files_buffer ) return result @@ -84,6 +89,9 @@ frame_slab_allocator :: proc() -> Allocator { return result } +// TODO(Ed): Rethink usage of transient arena, slab may still be useful but we need to think of the heursitic when this will be actively used +// String generation should use a chained arena, they should never exceed 64 mb or the max threshold (correct?) +// Dynamic arrays that last for a while maybe but are temp for complex workloads? Dynamic hashtables using arrays/arenas? transient_slab_allocator :: proc() -> Allocator { result := slab_allocator( get_state().transient_slab ) return result diff --git a/code/sectr/grime/pkg_mappings.odin b/code/sectr/grime/pkg_mappings.odin index f891eba..9afe3dd 100644 --- a/code/sectr/grime/pkg_mappings.odin +++ b/code/sectr/grime/pkg_mappings.odin @@ -267,10 +267,10 @@ import "codebase:grime" djb8_hash :: grime.djb8_hash // linked lists - LL_Node :: grime.LL_Node + SLL_Node :: grime.SLL_Node - ll_push :: grime.ll_push - ll_pop :: grime.ll_pop + sll_push :: grime.sll_push + sll_pop :: grime.sll_pop DLL_Node :: grime.DLL_Node DLL_NodeFull :: grime.DLL_NodeFull diff --git a/code/sectr/ui/core/base.odin b/code/sectr/ui/core/base.odin index 128a251..e2ea635 100644 --- a/code/sectr/ui/core/base.odin +++ b/code/sectr/ui/core/base.odin @@ -120,7 +120,8 @@ UI_BoxCache_TableSize :: 32 * Kilobyte // TODO(Ed): Rename to UI_Context UI_State :: struct { - // TODO(Ed) : Use these? + // TODO(Ed) : Use these? Right now the way our hashtable does things is it implicitly uses a pool allocator. + // We could instead use an arena (CR) allocator, if it chains it won't matter because the boxes are only accessed purely as a DAG. // build_arenas : [2]Arena, // build_arena : ^ Arena, @@ -141,11 +142,13 @@ UI_State :: struct { // render_list : Array(UI_RenderBoxInfo), render_list_box : Array(UI_RenderBoxInfo), render_list_text : Array(UI_RenderTextInfo), - + // TODO(Ed): We can have multiple list sets, one towards working-set, and the one enqueued for rendering (a buffered list matching the framebuffer) + // We can back these by arenas? Do we want them persistently on the slab? + null_box : ^UI_Box, // This was used with the Linked list interface... root : ^UI_Box, - // TODO(Ed) : Look into using a build arena like Ryan does for these possibly (and thus have a linked-list stack) + // TODO(Ed) : Look into using a build arena like Ryan does for these possibly (and thus have a linked-list stack) (Chained Arenas) layout_combo_stack : StackFixed( UI_LayoutCombo, UI_Style_Stack_Size ), style_combo_stack : StackFixed( UI_StyleCombo, UI_Style_Stack_Size ), parent_stack : StackFixed( ^UI_Box, UI_Parent_Stack_Size ), diff --git a/code/sectr/ui/layout_widget.odin b/code/sectr/ui/layout_widget.odin index 8054e62..859cb50 100644 --- a/code/sectr/ui/layout_widget.odin +++ b/code/sectr/ui/layout_widget.odin @@ -1,10 +1,8 @@ package sectr -import "base:runtime" -import lalg "core:math/linalg" - /* Widget Layout Ops -TODO(Ed): Review this file, these are can now be done with ui_box_compute_layout +For complex layout operations that are not supported by the core's auto-layout system. */ +