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

Reply via email to