Open mulle-nat opened 4 months ago
sooooooooooo i'm currently thinking about what all ought happen for 4.0, and i'll look into this for that scope.
One more suggestion for 4.0.0: It would be nice to have ncplane_cell_ref_yx
exposed, because the checking code piles up over the two dimensional looping. Since ncplane_at_yx_cell
is not inline, an optimizing compiler can not hoist the checks out of the loop. With ncplane_cell_ref_yx
exposed, you could turn ncplane_at_yx_cell
into an inline
function with basically zero overhead compare to ncplane_cell_ref_yx
.
Currently it seems, I can't have a
ncplane
without a parent ncplane. There is one exception noted in the source:ncdirect
gets internal APIncplane_new_internal
to create a rootless plane. After all, such planes are convenient, but no dice for the stinking API coder :wink: .The only way to maintain
nccell
information outside of a ncplane are unwieldy private ncplane/nccell copies (you can't reuse the ncplane struct , because a) its internal api and b) you need a parent). You also can't reusenccell
because it needs a plane for storage. So the API coder writes code like at the bottom of this issue (an extended rgb.c demo). The amount of copying going with astrdup
for each cell is just not nice. With a parentless ncplane, ancplane_copy
function would just need tomemcpy
all the cells andstrdup
the egcpool or ?With parentless planes, you can also do operations like temporarily hiding and showing a plane much easier:
should do the trick. Generally I would prefer to setup my ncplanes first completely "offscreen" so to speak and then assemble them myself in z order before rendering. That would be easy with rootless planes, impossible without.
I am not sure if all my troubles went away if ncplane could be rootless, but it feels like it.