Odd GLFW window & Min specs

[drunlade]

Two Three questions:

(1) We've had reports that our application (running under Windows, unsure of version yet) is producing a large blank white window with the title "GLFW message window" and nothing else. What could be causing this? This possibly started when moving from 2.6.2 to 2.7.1 (or to dev) but that's not confirmed yet.

(2) What is the min spec for running Fyne, realistically? We have someone running our app on some 6 year old Celeron mobile orientated processor with weak integrated graphics and 4Gb of RAM and they say it's very jerky and slow (note this is running a termgrid which I think it self is quite heavy in Fyne currently?).

(3) Some of the machines our software is deployed to are very old / weak hardware. Is it possible to reduce things like the internal frame-rate that Fyne operates on? My assumption is it operates at 60fps, but I may wish to drop that to 30fps on weak (old) hardware that just can't keep up. I don't see any obvious way to achieve that.

[andydotxyz]

(1) We've had reports that our application (running under Windows, unsure of version yet) is producing a large blank white window with the title "GLFW message window" and nothing else. What could be causing this? This possibly started when moving from 2.6.2 to 2.7.1 (or to dev) but that's not confirmed yet.

Is "GLFW message window" the title of your window? If not then it sounds like something is wrong with the OpenGL configuration of the computer - have they recently upgraded OS or drivers? Check everything is up to date.

(2) What is the min spec for running Fyne, realistically? We have someone running our app on some 6 year old Celeron mobile orientated processor with weak integrated graphics and 4Gb of RAM and they say it's very jerky and slow (note this is running a termgrid which I think it self is quite heavy in Fyne currently?).

It should work well on much less than that. Raspberry Pi works, for example. I have done trade show demos where a RPi and a 7" touch screen run an app for hours with constant animations and no problems.
I have no knowledge of termgrid being "heavy" (I'm assuming you mean TextGrid).

(3) Some of the machines our software is deployed to are very old / weak hardware. Is it possible to reduce things like the internal frame-rate that Fyne operates on? My assumption is it operates at 60fps, but I may wish to drop that to 30fps on weak (old) hardware that just can't keep up. I don't see any obvious way to achieve that.

Frame rate is almost irrelevant. It is used only to drive animations or UIs that otherwise change more than 60 times per second. It sounds like your app is driving a lot of change that could be causing CPU usage.

[drunlade]

Is "GLFW message window" the title of your window? If not then it sounds like something is wrong with the OpenGL configuration of the computer - have they recently upgraded OS or drivers? Check everything is up to date.

We were unable to replicate the user's reported issue with a normal version of the application. And yes, the window title was that, the window it self was empty (white). I did replicate the issue under a VM by setting the tag gles for a test build, so I assume yes it's driver related. What's odd is the user reported it only does it sometimes. I'm looking into possibly deploying a version of the program with it's own opengl32.dll driver (an alternate wrapper driver).

That being said, can I assume this isn't something Fyne could spot/detect/report on, as it's likely lower level driver problems (such as missing driver, or a driver that's not correctly compatible)?

It should work well on much less than that. Raspberry Pi works, for example. I have done trade show demos where a RPi and a 7" touch screen run an app for hours with constant animations and no problems. I have no knowledge of termgrid being "heavy" (I'm assuming you mean TextGrid).

I mean widget.TermGrid which yes is wrapper around TextGrid. A RPi probably has much stronger graphics hardware (especially drivers) than an old intel Celeron that uses extremely weak Intel Integrated graphics. It might also have terrible OpenGL drivers, I strongly suspect it's using software rendered mode.

For example here is a clean build of the Fyne Terminal (off latest master) running under the Windows 11 VM, I'm pretty sure the OpenGL driver is using software rendering given that CPU usage. However, even if it is using a software render mode, it's still extremely high for what is not a lot of terminal change (there's some blinking text, with a blink rate of around 800ms).

Frame rate is almost irrelevant. It is used only to drive animations or UIs that otherwise change more than 60 times per second. It sounds like your app is driving a lot of change that could be causing CPU usage.

Indeed, as discussed in the PR, I assumed the tick-rate would cause a frame-per-tick which was not correct (at least, it's not designed to do that).

I have run this through profiling, the largest (by a long way) use of time is in the gl path, culminating in 58% cgocall. I don't know if that is "as expected" though.

Is there a flag I can set that will log every time the driver actually triggers a draw call? It'd be very useful to see that as I can then understand what code changes in the app cause excessive draw calls.

[andydotxyz]

I mean widget.TermGrid which yes is wrapper around TextGrid.

If there is a performance issue it's likely in the terminal repo - there is no TermGrid widget in the fyne widget package.

Is there a flag to log render calls?

Not yet - that could be a nice addition to "-tags debug" mode. The best way I have seen this done is with a heatmap overlay which would be cool.

Regarding all the usage in the gl package this is worrying. A software renderer issue would be inside the C layer (after the syscall) being in Go space points to something else - possibly a really slow float32 processor or some hot loop in the app which just is not noticeable on other hardware.

For reference running "top" inside a Fyne terminal takes around 2-3% CPU on my end iirc - we might need to look at the pprof in more detail. I'm not yet convinced there is a problem in Fyne but we should find out.

[drunlade]

If there is a performance issue it's likely in the terminal repo - there is no TermGrid widget in the fyne widget package.

Most likely. I'll dig into it if I find the time, things are busy end of year!

Not yet - that could be a nice addition to "-tags debug" mode. The best way I have seen this done is with a heat-map overlay which would be cool.

Heat-map would be nice, though even just a draw-counter that ticks up every time it's invoked would be helpful.

Regarding all the usage in the gl package this is worrying. A software renderer issue would be inside the C layer (after the syscall) being in Go space points to something else - possibly a really slow float32 processor or some hot loop in the app which just is not noticeable on other hardware.

Ah, in which case I'll run it again and share the profile if that'd be useful?

[andydotxyz]

Heat-map would be nice, though even just a draw-counter that ticks up every time it's invoked would be helpful.

For counters though what is the "it" that we want to count? The fact that a screen was painted does not mean that widgets refreshed etc - it is possible only one item updates then the rest of the UI is pulled from texture caches.

Ah, in which case I'll run it again and share the profile if that'd be useful?

That would be ideal thanks.