Hi, Thanks for the suggestion. Although it doesn't qualify for a quick fix, I guess it's a possibility if there is no other way of accomplishing this.
BTW, is it intentional to make the member variables of Fl_Group protected and nothing but the destructor virtual? Makes it hard to derive from and specialize... /Andreas > > On 6 Feb 2010, at 14:30, Andreas Ekstrand wrote: > > > > We use an Fl_Scroll with a large number of buttons to accomplish a > > fancy tree-view in our application. After an update to the latest > > FLTK 1.3, we discovered a major fall in performance when clearing > > the scroll in order to re-calculate the graph represented in the > > Fl_Scroll. > > > > We use Fl_Group::clear explicitly, I think Fl_Scroll::clear was > > even slower. The problem is that in a graph with e.g. 8000 children > > on one level, the new implementation of Fl_Group::clear which I > > think was introduced January 8, 2009, is way to slow for us, > > removing each child separately. The old implementation where the > > complete array was cleared at once was much faster. > > This is going to be a deeply unhelpful observation (sorry) but the > mechanisms used to hold and manipulate the list of widgets inside a > group / scroll were really only meant to cope with a small set, maybe > a few tens of widgets. > > They really are "sub-optimal" for manipulating a collection of 8,000 > or more... > > When I encountered this problem in the past (this was way back with > late fltk-1.0, early fltk-1.1, IIRC) I made my own container to > "efficiently" manage the list of items, then made a "fake" scroll > view out of a couple of scrollbars and a subclass of Fl_Box, so that > I only ever had to render the few dozen items that were actually > visible, and only needed a small handful of actual widgets to exist > to do this. > > This was substantially faster than simply stuffing many widgets into > the Fl_Scroll... Was a bit tricky to get the item viewport stuff > going, mind you. > > However - it sounds like it is *way* to late for me to be making that > suggestion, you are already well past the point at which it would be > practical or useful... > > > > > Perhaps you could re-introduce the old implementation in a separate > > method or with a boolean parameter to the clear method? > > Unlikely - the change was made to address specific bugs, so... > > > We are looking for a quick solution here, since we want to use the > > latest FLTK 1.3 with our next patch release of our software. > > Sorry, don't really know what else to suggest... > > > _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
