>> The way I see it, if the selection list is managed as an array >> of item ptrs (instead of as a per-item bit flag), then when >> Fl_Tree runs its draw() loop, wouldn't it have to do a lookup >> on this array each time it has to check if an item is selected >> (in order to draw it properly)?
> The indirection lookup in the selection data structure could actually > eat a lot of cpu if you use a non suitable abstract data type.. Right, but no matter how you optimize 'the lookup' (hash, bsp, etc), it's still a "lookup", vs. a simple "if (selected)" test on a bit flag. So doing this (I think) ends up making everything "draw slower" and at a potentially large memory cost (eg. ^A). For these reasons I think it should at least be an option, eg: set_manage_selection_list(0|1). This way the app will internally manage both the selection bitflag *and* the selection array; the selection bitflag is zero overhead to manage, and the selection array would do what it needs to do if enabled. The docs for this option would have to point out that, when enabled, seemingly simple methods like select(), deselect() etc may incur malloc()/realloc() overhead, lookups, etc. Thing is, I'd really like to delay implementation of this until Fl_Tree has stabilized wrt to adding new features, as I think implementing it would complicate a lot of the code; everything from sorting to mouse selection/event management, etc. _______________________________________________ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
