Delaying recalc seems a fine solution, but it can have some obvious side effects; if recalc is deferred, apps (and derived classes) that depended on the calculations of scrollbar sizes be updated will now not see these calculations done until the first draw().
An example I can think of is an app that repeatedly append()s text to the widget, and tries to keep the screen scrolled to show the last line of text based on the scrollbar position, which now isn't calculated until the next draw().
We can't be certain existing apps (and derived classes) may break in interesting ways if they these calculations are suddenly deferred unconditionally.

I'd suggest for backwards compatibility this be considered an "option" that is off by default, and can be turned on by apps (and derived classes like Fl_Simple_Terminal) that need it.

We could add some docs to the Fl_Text_Display/Editor intro that warns if editor operations seem slow during repeat calls to methods that manipulate the editor, to recommend turning on this "deferred recalc" option, and reference the benefits and drawbacks.

I'm not really sure what to call such an option.. whatever we come up with should be forward thinking, in case we want other complex widgets to have a similar flag.

deferred_recalc() sounds a bit nerdy and unobvious to an app developer.. maybe delayed_recalc_display(true|false) or recalc_display_on_draw(true|false)?

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <fltk/fltk/issues/300/1221766748@github.com>