Albrecht Schlosser wrote:
> Andreas Ekstrand wrote:
>
>> The problem is that in a graph with e.g. 8000 children on one level,
>
> That's really many children. Fl_Group is not designed to hold that
> many children, although there's no reason why it wouldn't work.
>
> Do you have any numbers (times) how much slower the new implementation
> is? If yes, on what hardware and OS?
I just remembered that we added another performance degrading function
that might hit you. If you delete many widgets that don't have their
own callback() (i.e. use the "default" callback) then there can be
another problem because the default callback queue is now cleaned
in the destructor of widgets with the default callback.
You can try to do something like this before deleting the widgets
in your Fl_Scroll:
int nd = 0;
while (Fl::readqueue()) nd++;
printf ("cleared Fl::readqueue(): %d events deleted\n",n);
[Note: nd and printf are only intended for testing].
There is a maximum of 20 pending events in this queue, but if
this must be checked for 8000 widgets... It would be interesting
to know if there are entries in the queue at all.
Note that this does only delete events that would have been
read with Fl::readqueue(), but if you don't use this, it
shouldn't do any harm. Currently the standard dialog functions
like fl_ask, fl_message, fl_input are using it for instance,
but there's nothing lost if the queue is cleared every now and
then.
Albrecht
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
