[vim/vim] GTK3: GUI slow on X11 since dropping the surface alpha channel (after v9.2.0646) (PR #20634)
h_east
Problem: With the GTK3 GUI, scrolling and moving the window are slow on
X11 since 9.2.0646, on setups where the accelerated drawing path
expects an ARGB surface.
Solution: Choose the offscreen surface content per display backend: keep the
alpha-less surface on Wayland, where it avoids needless alpha
compositing, and use an ARGB surface on X11 again, which is the
accelerated path there, restoring the speed.
You can view, comment on, or merge this pull request online at:
https://github.com/vim/vim/pull/20634
Commit Summary
- 1dec673 GTK3: GUI slow on X11 since dropping the surface alpha channel (after v9.2.0646)
File Changes
(1 file)
- M src/gui_gtk_x11.c (18)
Patch Links:
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
h_east
h-east left a comment (vim/vim#20634)@dezza (as the author of patch v9.2.0646)
It would be greatly appreciated if you could check that this doesn't cause any regressions on the Wayland backend.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
dezza
dezza left a comment (vim/vim#20634)https://gitlab.gnome.org/GNOME/gtk/-/blob/3.24.51/gdk/gdkscreen.c#L947
https://gitlab.gnome.org/GNOME/gtk/-/blob/3.24.51/gdk/gdkscreen.c#L979
https://gitlab.gnome.org/GNOME/gtk/-/blob/3.24.51/gdk/gdkscreen.c#L1003
These might be worth considering.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
h_east
h-east left a comment (vim/vim#20634)@dezza
I apologize, but I'm not quite sure how I should utilize those APIs.
Does this mean the current implementation in the PR is not sufficient?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
h_east
h-east left a comment (vim/vim#20634)I looked into the APIs you suggested above, but it seems they don't exactly align with what we need for this specific case.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
dezza
dezza left a comment (vim/vim#20634)I came to same conclusion, just a quick thought as we really should try to lean into the GTK/GDK API more.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
h_east
h-east left a comment (vim/vim#20634)I came to same conclusion, just a quick thought as we really should try to lean into the GTK/GDK API more.
I agree, but since I don't use gVim on Linux except for debugging gVim itself, I've been hesitating to look into it. On top of that, I run Linux as a guest OS inside VirtualBox on a Windows PC, and this weak environment is another reason. 😅
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
dezza
dezza left a comment (vim/vim#20634)I came to same conclusion, just a quick thought as we really should try to lean into the GTK/GDK API more.
I agree, but since I don't use gVim on Linux except for debugging gVim itself, I've been hesitating to look into it. On top of that, I run Linux as a guest OS inside VirtualBox on a Windows PC, and this weak environment is another reason. 😅
I'm working on improving the 'editexisting.vim' script in 'opt/dist`. It currently opens all files via terminal vim to the first "master" vim.
My version works with gvim, plasma, kdotool. It raises window focus of gvim so it hovers above other windows and goes to the right tab, window.
I believe this makes less friction because; multiple tmux panes, multiple vim is hell. If you have proper reloading, one gvim to rule all and it reduces context switching.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.