@Albrecht-S yes, we want to avoid a "bug fix oscillation" where one bug's fix is another bug's bug.
There's a few times in FLTK where I've seen such oscillations span a decade or more, where it goes back and forth - so much time between the fixes, no one remembers the back-and-forth.

Luckily the commits show the related bugs clearly.

This is going to be really annoying to fix, but the penalty in time is huge; just doing 500 string appends, let alone the calls to scroll() and remove(). We've known for a while Fl_Text_Xxx can get really slow just because of the scrollbar calculations. There must really be a way to do this better, keeping a running maximum for the width and height so these recalcs don't involve so much cpu.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.