|
|
Michael Sweet wrote:
Stan wrote:
I implemented this by using insert() to add each component at its
(currently) correct position. When the grid is large, this is
rather slow. Performance is obviously much better if I add()
each component, then sort the Fl_Scroll's array of children
when I'm all done. It seems to work, but I'm wondering if it's
safe to do.
If Fl_Group::insert() is slow, it's probably because of the
linear search that occurs when Fl_Group::insert() calls
Fl_Group::find() to locate the insert position.
You can probably optimize this a bit by making either a
'row widget' or a 'column widget' (which ever suits your app better),
so that the Fl_Group just has an array of, for example, row widgets..
so sorting by column only involves walking the number of rows
and moving them around together.
The row widget itself might be an Fl_Group to handle column
arrangements.
Even sorting columns with a row oriented arrangement will still
sort faster, because when you determine the sort order for the
columns, moving the columns around doesn't involve walking the
entire widget array during the insert()/find() operation, just
the widgets in each column.
Basically, anything you can do to either shorten the find()
or decrease the number of insert()s you do will speed things up.
Maybe you don't even need to call insert() if your just moving
widgets around, since 'sorting' has more to do with the widget
x/y positions than it does with their position in the internal arrays.
Unless you're using an Fl_Tile instead of Fl_Group, in which case
array positions would matter.
[ Direct Link to Message ] | |
|
| |