DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New] Link: http://www.fltk.org/str.php?L2409 Version: 1.3-feature Interesting: I made a test program that created 20k buttons to test the problem; see attached test-clear.cxx. If you hit any of the buttons, it (1) clear()'s and (2) re-recreates the buttons. Messages are printed to stderr showing how long these two operations take. (ie. the time it takes for the 'Done' message to appear) It took ~3 seconds for the clear() operation, and no perceivable time at all to build the 20k buttons. So definitely easy to replicate. I tried optimizing the two things in clear() that seemed to involve loops that could be optimized: 1) Avoiding the find() lookup by making a remove(int) so that items could be removed by index, and calling that to remove the widget. There's still a loop in remove(int) to shuffle down the array, so followed up with a second change.. 2) Avoiding the 'remove shuffle' by starting the clear() at the /end/ of the array, and working downward. (Albrecht warned against doing this for other reasons, but I wanted to see how it affected speed, since doing this prevents the 'shuffle' of the array completely.) Interestingly, neither affected the speed noticeably at all..! (Albrecht: you can insert an "I told you so!" here ;) So indeed, seems the problem is deeper. Albrecht suspected event deliveries during widget destruction that might be the cause, which means code entirely outside of the clear() and remove() code would be at issue. Link: http://www.fltk.org/str.php?L2409 Version: 1.3-feature _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
