You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently it seems, I can't have a ncplane without a parent ncplane. There is one exception noted in the source: ncdirect gets internal API ncplane_new_internal to create a rootless plane. After all, such planes are convenient, but no dice for the stinking API coder 😉 .
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 reuse nccell 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 a strdup for each cell is just not nice. With a parentless ncplane, a ncplane_copy function would just need to memcpy all the cells and strdup the egcpool or ?
With parentless planes, you can also do operations like temporarily hiding and showing a plane much easier:
// hideoldparent=ncplane_parent( n);
ncplane_reparent( n, NULL);
// showncplane_reparent( n, oldparent)
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.
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 😉 .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.
The text was updated successfully, but these errors were encountered: