I just tried the below one liner fix.. seems to completely prevent
the "remove() array shuffle".
Offhand, I can't see how this change could break anything otherwise.
If this change *sounds kosher to the devs* and *OP can verify it helps*,
I'll check this mod into fltk 1.3.x.
It should probably be done anyway, cause it's definitely coded in
the worst-case way right now wrt to remove()'s implementation.
Greg Ercolano wrote:
> Offhand I'd say say clear() seems to be doing the slowest thing possible
> wrt to how remove() currently operates.
>
> remove() shuffles the array downward to fill in the new gap,
> so if you always remove the first element, the entire array above it
> has to
> shuffle downward.
>
> It seems to me if clear() started at the end of the array and worked
> its way
> downward, each remove() operation wouldn't have to do any shuffling.
>
> If I understand things correctly, this might be a one liner fix
> to Fl_Group::clear(), specifically in this section:
>
> while (children_) {
> //Fl_Widget *o = child(o); // <-- COMMENT THIS OUT
> Fl_Widget *o = child(children_-1); // <-- USE THIS INSTEAD
> if ( o->parent() == this ) {
> remove(o);
> delete(o);
> } else {
> remove(o);
> }
> }
>
> I didn't try this, but I *think* that will help remove()
> do less work on each iter.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
