more review
This commit is contained in:
@ -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
|
||||
}
|
||||
|
||||
|
@ -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,
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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 ),
|
||||
|
@ -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.
|
||||
*/
|
||||
|
||||
|
Reference in New Issue
Block a user