ed/SectrPrototype
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

more review

Browse Source
This commit is contained in:
Edward R. Gonzalez
2025-07-04 14:40:25 -04:00
parent b15503c079
commit 87d5cda2c0
6 changed files with 29 additions and 20 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
code/sectr/app/state.odin
View File

@ -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

6
code/sectr/grime/pkg_mappings.odin
View File

@ -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

9
code/sectr/ui/core/base.odin
View File

@ -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 ),

6
code/sectr/ui/layout_widget.odin
View File

@ -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.
*/