FLTK runs very slow on Macbook's built-in display vs external display

[Adrian En]

Hi all,

I am building an emulator app with GUI using FLTK, and noticed a bug (probably because I am not using FLTK properly), where my program runs (in term of refresh rate) 4x times faster on external display, than my macbook's builtin display.

Here is a video recording of this issue: https://youtu.be/68jOl6_1kRQ

As you can see, when I move the window out of view to external display, the FPS jumped.

I put together a minimal code base to reproduce this, you can find it here: asvrada/tmp-fltk-issue-demo (github.com). It assumes the FLTK headers are located at /usr/local/include

A little breakdown of the code: I am writing an Intel 8080 CPU emulator to run the classic Space Invader, I override a Fl_Box's draw() method to draw the game, and calls redraw() during every loop. Am I doing this correctly? Am I using double buffered window correctly?

Thanks,

Zijie

[Ian MacArthur]

Without seeing more of your code, it's hard to know for sure, but based on what you report it sounds to me as if you have, in effect, tied the update of the emulator to the display.

Generally, that's a Bad Idea, you'll probably want to allow the emulation to run at the "correct" speed, and have the update of the display run asynchronous to that.

In this case, my experience suggests that Apple (and indeed most manufacturers) tie their "default" display refresh rate to the monitor frequency of their laptops (likely 60Hz in an Apple laptop)  and so if your emulation is tied to that, that's going to constrain how fast it runs.

Display updates to an external display may well be (and often are) "free running" and so will not be constrained by the monitor refresh rate (and indeed the external monitor may well have a higher refresh rate anyway...)

You can try an experiment with the fractals demo from the test folder, see what FPS it reports on each of the monitors - that (I suspect) may show a similar disparity.

But the main tip would be *not* to tie the running of the app to the refresh rate of the display. 

The display only *needs* to update slowly, in human timescales, whereas you want your application to run fast in "computer" timescales...

[Albrecht Schlosser]

On 3/30/23 05:40 Adrian En wrote:

Hi all,

I am building an emulator app with GUI using FLTK, and noticed a bug (probably because I am not using FLTK properly), where my program runs (in term of refresh rate) 4x times faster on external display, than my macbook's builtin display.

Here is a video recording of this issue: https://youtu.be/68jOl6_1kRQ

As you can see, when I move the window out of view to external display, the FPS jumped.

Adrian, I looked at the video and I can see the effect. Please see Ian's reply for technical details. I agree with Ian's statements.

That said, please do us (the FLTK developers) a favor and rename your youtube video. "FLTK Bug" is not a good description, particularly if it turns out that it is not a bug of FLTK itself. This title is misleading. Thank you.

I put together a minimal code base to reproduce this, you can find it here: asvrada/tmp-fltk-issue-demo (github.com). It assumes the FLTK headers are located at /usr/local/include

A little breakdown of the code: I am writing an Intel 8080 CPU emulator to run the classic Space Invader, I override a Fl_Box's draw() method to draw the game, and calls redraw() during every loop. Am I doing this correctly? Am I using double buffered window correctly?

I looked at your minimal code example but didn't test it. What it does is probably best described as "how often can I draw to the display?". If Ian's assumptions (WRT Apple's display refresh rate) are correct then the result is obvious.

A better scenario for your game would be to run the game engine in a thread with its own timer and display the current view of the scene in a timer loop with a constant refresh rate: decoupling the game and the view, as Ian wrote.

I'm not a gamer, but from what I read about games there's often a way to switch details (resolution and maybe more) on and off or increase the details by a value and measure the frames per second generated. FLTK however is different, and you should not try to get the highest possible frame rate in the way your demo does by drawing over and over again. Even the lowest frame rate I've seen in your demo (greater than 40) is higher than a human can recognize. Drawing with this frequency is just a waste of resources.

[Adrian En]

Thanks for replying! I will check my code and make improvements.

--
You received this message because you are subscribed to a topic in the Google Groups "fltk.general" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fltkgeneral/kKFkIxcD6V0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fltkgeneral...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/d02e01a7-3c9d-d741-d3af-17dc2fd9c906%40online.de.

[Albrecht Schlosser]

On 3/30/23 19:03 Adrian En wrote:

Thanks for replying!

Welcome. And thank you for renaming the youtube video!

I will check my code and make improvements.

OK, please feel free to ask further questions here. We're always glad if we can help.