On 04/17/12 06:49, Fabien Costantini wrote:
> Also, on the previous & related Fl_Tree design discussion(selection list
> as opposed to traverse tree like selection approach) , I wouldn't buy the
> performance point on redraw() as you still know what to be redrawn from
> 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)?
Effectively, the pseudocode:
for (item=first_visible_item; item<last_visible_item; item++ ) {
if ( is_item_selected(item) )
draw_selected()
else
draw_unselected()
bool is_item_selected(item) {
for (i2=0; i2<total_selected_items(); i2++) //
argh: lookup loop
if ( item == selected_array[i2] ) return(true);
return(false)
}
..the problem here being here 'is_item_selected()' becomes
a lookup on a potentially large array, instead of a bit flag test.
If someone did a ^A (select all) on 80k widgets,
the selected_array[] would become 80k large, and so that
array would need to be walked to draw each item.
And whenever the selection is modified (eg. with a Ctrl-Drag
or Shift-Drag), again the array needs to be walked on each
update.
This, as opposed to walking the array once whenever someone
wants to get the selection as an array (ie. a convenience
function). Isn't it better to do that, to prevent constant
array lookups?
I think a bitflag is the better approach, and just compute
the selection list when it's requested (as a single pass at
the array)
_______________________________________________
fltk-bugs mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-bugs
