UI is very slow with a high resolution/refresh rate monitor

[KSPAtlas]

I've been trying to use DrRacket, but the UI is significantly slower than most other programs, especially when filling the entire screen (decreasing the size of the DrRacket window helps a little, but it's still slow).

Actions like switching tabs can take seconds, in which the program is completely unresponsive.

• Resolution: 3440 x 1440 (WQHD)
• Refresh rate: 180 Hz
• Linux distribution: NixOS (used DrRacket from the nix package)
• Windowing protocol: Wayland
• Window manager: Sway
• Graphics card: NVIDIA GTX 1650 (Proprietary drivers, open kernel modules)

[LiberalArtist]

My guess is that the part of your configuration most different from what other people use is the 180 Hz refresh rate. (FWIW, my laptop is 3840x2400@60Hz on an Intel card, running KWin/Wayland on Debian Bookworm with DrRacket from the Guix package.)

Are you able to try a lower refresh rate temporarily and see if the problem persists?

Do you have HiDPI scaling on your display, and, if so, is it 200% or something fractional?

Another thing to note is that racket/gui still uses GTK 3. It's possible there's some improvement in GTK 4 that we don't have. Do you have similar problems with any other applications?

[KSPAtlas]

No, I don't use any form of HiDPI scaling.

Switching to 60Hz has no effect on the GUI performance. The GUI performs fine when it's not doing tasks like opening tabs, windows etc, but when it is the entire GUI locks up (including stuff like hover-over animations) until the task is done. Also no, I don't have problems like this with other applications

[rfindler]

Would it be possible for you to make a short movie to show us what you mean exactly? It is known that when the window is large (and the file isn't short) that scrolling (and some other editing operations) are slow. But that would go away when you made the window smaller, so there may be some other, simpler problem here too.

[KSPAtlas]

@rfindler Whoops, never noticed your reply, here's a video that I took when it happened but ended up not sending

S7AkgRZ.mp4

[KSPAtlas]

Here's a trace from DrRacket where I was doing similar things to the video:

[rfindler]

Thanks; it does seem to be something slow at the wx layer (or in the GUI system of the platform) somehow. Can you share the entire profile, instead of just a screenshot of the start of it. (Just looking at what's here, I don't see anything that actually takes time, just things that'll tend to be on the top of the stack.)

Also, can you share what you did to get that profile?

[KSPAtlas]

@rfindler The command I used was PLTDRPROFILE=1 drracket, and I've attached another profile I did (note that I changed desktop environments, but this is also reproducible on COSMIC)

racket.log

[rfindler]

Thanks for the complete log! (Thanks also to @mflatt for detective help here.)

It looks like a problem is that do-on-paint is called 6353 times. Those callbacks originate in either the "expose-event" or the "draw" callback. Maybe we can see what's going on if you were to add a printf into those two to figure out which one is getting called so many times?

[mflatt]

One more thought: Does it matter whether you're using a tiling window manager like Sway or something else? One possibility is that the Racket GUI toolkit is fighting with the window manager over a window's size, and that keeps triggering refreshes. I don't see that effect when I try Sway myself, but it would be good to rule it out.