OK, won't change.

Indeed, sounds like there should be a new remove(int index),
since internally Fl_Group uses an array[], not a linked list,
so that's the most optimal approach, given the public way to access
the list is with child() and chidren(), which are both index oriented.


Albrecht Schlosser wrote:
> Greg Ercolano wrote:
>>     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 :-(
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev

Reply via email to