Greg Ercolano wrote:
>
> 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.
No, please don't do that. There are reasons why I did it this way.
It has something to do with composite (but not Fl_Group) widgets
that can have their own "sub-widgets" that are children of the same
parent group as the main widget. In this case we must delete the
"main" widget first, and the current way lets the main widget delete
the sub-widgets from the group in its own destructor (if we assume
that the sub-widgets have been added to the group later than the
main widget).
> It should probably be done anyway, cause it's definitely coded in
> the worst-case way right now wrt to remove()'s implementation.
I tried some other ways to improve this. When testing it turned out that
something's going on with multiple throw_focus() and similar functions
being called a lot. I tried to investigate it, but got stuck. Anyway,
I found out that reverting the order of removal didn't gain much WRT
the time that was used with all these throw_focus() calls. Remember
that Andreas wrote about 20,000 widgets in the group. I used a test
program with up to 100,000 widgets and could see the effect clearly,
but didn't find a way to fix it yet.
If we would start at the end of the array, this would have another
time consuming effect, since Fl_Group::remove() calls Fl_Group::find(),
and this searches the child array and compares each pointer until it
finds the correct child (which would then always be the last). There
should probably be another Fl_Group::remove(int i) method that uses
the index to remove the child...
I still have my test environment in place, but didn't find the time to
continue this since weeks. Sorry, Andreas :-(
> 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.
Albrecht
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
