Bug #11721
openGlitchy scroll on Ubuntu
Added by Micael Jarniac 17 days ago. Updated 17 days ago.
0%
Description
When scrolling, the screen doesn't seem to refresh fast enough, resulting in very glitchy and sluggish scroll.
I'm on Ubuntu GNOME with Wayland.
This seems related to the following issue:
https://chirpmyradio.com/issues/10172
Files
| config.txt (1.77 KB) config.txt | Micael Jarniac, 12/04/2024 04:39 PM | ||
| UV-5R v2.img (8.43 KB) UV-5R v2.img | Micael Jarniac, 12/04/2024 04:39 PM | ||
| debug_log.txt (112 KB) debug_log.txt | Micael Jarniac, 12/04/2024 04:39 PM | ||
| Screencast from 2024-12-05 00-54-19.mp4 (335 KB) Screencast from 2024-12-05 00-54-19.mp4 | Micael Jarniac, 12/04/2024 07:54 PM |
Updated by Micael Jarniac 17 days ago
- File config.txt config.txt added
- File UV-5R v2.img UV-5R v2.img added
- File debug_log.txt debug_log.txt added
[Uploaded from CHIRP next-20240905]
Updated by Dan Smith 17 days ago
Yup. CHIRP uses wxwidgets for cross-platform UI compatibility and wxGTK has always been a bit problematic on Wayland. On 24.04 it seems worse (but still usable, IMHO). You can try setting GDK_BACKEND in the environment:
$ GDK_BACKEND=x11 chirp
Which seems to make it less chunky for me, but maybe also not as responsive.
Also, I don't think it's a "refresh fast enough" problem as in my experience you can drag the scroll bar on the right at pretty high speed and it responds just fine, it's the scroll wheel input that gets delayed, batched, or whatever.
Updated by Micael Jarniac 17 days ago
Dan Smith wrote in #note-2:
Yup. CHIRP uses wxwidgets for cross-platform UI compatibility and wxGTK has always been a bit problematic on Wayland. On 24.04 it seems worse (but still usable, IMHO). You can try setting GDK_BACKEND in the environment:
$ GDK_BACKEND=x11 chirpWhich seems to make it less chunky for me, but maybe also not as responsive.
Also, I don't think it's a "refresh fast enough" problem as in my experience you can drag the scroll bar on the right at pretty high speed and it responds just fine, it's the scroll wheel input that gets delayed, batched, or whatever.
What I meant by not updating fast enough is that the scroll seems to always be "registered", but the screen doesn't "see" the new position right away. But if you click an element while the scroll is "stuck", it clicks at the new position, not the stuck position, if it makes any sense. So it's as if it had actually scrolled, but you just can't see it right away. Clicking then forces a segment of the screen to update. Taking a screenshot also seems to force the screen to refresh and display the new position.
Updated by Dan Smith 17 days ago
Ah okay, yeah I definitely don't see that corrupted redrawing on my system, just the slowness. Does it still happen with the GDK_BACKEND override I described above? That forces GTK to use the older x11 renderer.
Either way, CHIRP isn't involved in the low-level drawing or scrolling at all, that's all handled by the widget toolkit (wx) and the drawing engine it uses (gtk) so I'm not sure there's anything I can do about it.
Updated by Micael Jarniac 17 days ago
Dan Smith wrote in #note-4:
Ah okay, yeah I definitely don't see that corrupted redrawing on my system, just the slowness. Does it still happen with the
GDK_BACKENDoverride I described above? That forces GTK to use the older x11 renderer.Either way, CHIRP isn't involved in the low-level drawing or scrolling at all, that's all handled by the widget toolkit (wx) and the drawing engine it uses (gtk) so I'm not sure there's anything I can do about it.
The override seems to fix it.
And about wx, do you know where one could report this issue?
Updated by Dan Smith 17 days ago
Cool, if the override fixes it then it's almost definitely wx/GTK related I think. Technically chirp tries to set that internally but it no longer seems to be doing it early enough to matter. Can you try running chirp with --no-linux-gdk-backend to make sure it's not a problem of that being internally set halfway through initializing GTK or something? I should probably remove that hack altogether now that it doesn't seem to work.
I assume report here:
https://github.com/wxWidgets/wxWidgets
There are other wayland-related bugs, like this close to the top of the stack:
https://github.com/wxWidgets/wxWidgets/issues/24443
So there may be another bug you can find that is relevant.
Please be mindful that those people generally want a standalone reproducer (or to show that it happens on one of the demo apps they provide). They can't be expected to install and try CHIRP, dig through the code, etc. Just...please avoid asking them to support CHIRP :)
Updated by Micael Jarniac 17 days ago
chirp --no-linux-gdk-backend still has the problem.
Updated by Dan Smith 17 days ago
Okay, that's "good". I was able to move the initialization around a bit so that the current attempt to set GDK_BACKEND=x11 internally works again. So I'll queue that for a future build, which will make it default to x11 mode unless you pass that flag, which will make it wayland-native.