git bisect result: 0f58fc3.
related: #18002
related: #20513
It should have the same performance as versions before 9.2.0646.
9.2.699
—
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.![]()
Could you please run each of the following in your Vim and let me know the returned values?
:echo has('wayland') :echo $WAYLAND_DISPLAY :echo $XDG_SESSION_TYPE :echo $GDK_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.![]()
Thank you for your reply.
The command results are as follows.
:echo has('wayland')
1
:echo $WAYLAND_DISPLAY
# blank
:echo $XDG_SESSION_TYPE
X11
:echo $GDK_BACKEND
# blank
—
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.![]()
Thanks — that confirms the active backend is X11 (Wayland support is compiled in,
but $WAYLAND_DISPLAY is empty and the session is X11, so GTK3 is using the X11
backend).
9.2.0646 changed the offscreen drawing surface from CAIRO_CONTENT_COLOR_ALPHA
to CAIRO_CONTENT_COLOR (no alpha). On X11 this matters when the gvim window
uses a 32-bit (ARGB) visual: an alpha-less surface no longer matches the window's
format, so copying it to the window can fall off the fast same-format path. That
fits "fast before 9.2.0646, slow after" on an X11 + GPU setup.
To shape the fix (keep COLOR on Wayland, but match the window's format on X11),
two cheap checks would help:
xwininfo, click the gvim window, and reportDepth: line (24 or 32).xfconf-query -c xfwm4 -p /general/use_compositing.If the window is depth 32, that pins it down: the alpha-less surface from
9.2.0646 no longer matches the ARGB window, which is what costs the fast blit.
—
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.![]()
In my opinion, if gvim only uses X11 and does not need Wayland support, it should be fine to continue using CAIRO_CONTENT_COLOR_ALPHA as before...
The results of the command below.
Depth: is 24.xwininfo: Window id: 0x7000003 "[No Name] - GVIM2"
Absolute upper-left X: 1003
Absolute upper-left Y: 102
Relative upper-left X: 1
Relative upper-left Y: 26
Width: 916
Height: 973
Depth: 24
Visual: 0x2b
Visual Class: TrueColor
Border width: 0
Class: InputOutput
Colormap: 0x7000002 (installed)
Bit Gravity State: NorthWestGravity
Window Gravity State: NorthWestGravity
Backing Store State: NotUseful
Save Under State: no
Map State: IsViewable
Override Redirect State: no
Corners: +1003+102 -1+102 -1-5 +1003-5
-geometry 114x56-0-0
$ xfconf-query -c xfwm4 -p /general/use_compositing
true
—
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.![]()
I have created a PR that applies the change from 9.2.0646 only when the backend is Wayland.
I would appreciate it if you could verify the behavior.
—
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.![]()