Thanks for the suggestion. However, our widgets are using their own callbacks
and nothing was cleared.
/Andreas
> 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
