> > the externalized selection list and can rebuild your needed redraw > > context in similar ways though it now introduces ptr indirection. > > I'd like to understand what you mean, but I don't.. can you > elaborate? I'm probably missing something.. > > 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 : Without going back to universisty (!), just think of the proper data representation and you win: a list (linked or array) is bad for seeking element (the complexity is average n/2 for n elements) a much better approach for still getting great performances is to use either a binary search (log(n) complexity) or even better in our case a hashtable (almost constant complexity)
Now the funny thing about that discussion is that in the old days I published some experimentation made on fltk in my branch and had implemented widget lookup table which was just a hastable ... from scratch (no STL needed). It seemed that many users got & refered to this implementation I made but nobody used it in the core team. I even published performances results in these days. Ah the old days where I had (lot of ) spare time :) Peace. _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
