> > 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.
Simple -> yes, efficiently scalable probably not that much. > > So doing this (I think) ends up making everything "draw slower" > and at a potentially large memory cost (eg. ^A). Draw slower because of few ops (constant number of ops or log(N) increase) -> No, nothing you can possibly sense IMHO except if you redraw the tree 200 times per second (I'm kidding here). Larger memory -> Yes a bit more but nowadays, it would not make much difference on common (i.e. less than 15 years old systems?). these old systems could probably benefit running 1.1 instead 1.3 anyway. > For these reasons I think it should at least be an option, eg: > set_manage_selection_list(0|1). I now think there could actually be 2 implementations, one economical /simple one and another maybe already more scalable ? > 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. This was why at the first place I suggested to consider a tree impl. that did most of what we might have needed ? Anyway, I agree with you about the time factor and totally respect that. It is one thing to discuss features, something else to implement all these features, with not to many regressions ... Unfortunately, I just don't have as much time as I wished I would to be able not only to suggest / criticize existing functionality but actually help you more than I did last week to implement more of them. Thanks for keeping an open mind on that ones though, I think we already identified benefits from it and both took some actions. I'll look forward to new Fl_Tree features. _______________________________________________ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
