Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resizing on Wayland is broken #5162

Closed
zmike opened this issue Jun 2, 2022 · 7 comments
Closed

Resizing on Wayland is broken #5162

zmike opened this issue Jun 2, 2022 · 7 comments
Labels

Comments

@zmike
Copy link

zmike commented Jun 2, 2022

Describe the bug
Resizing a Kitty window on Wayland causes the resized redraw of the window to be a black rectangle.

To Reproduce
Steps to reproduce the behavior:

  1. Run Kitty on Wayland
  2. Resize the window with the mouse
  3. Black flickering rectangle during resize
  4. See error

Environment details

Kitty v0.25.1, unmodified configuration

Additional context
See also https://gitlab.freedesktop.org/wayland/weston/-/issues/624 wherein more info about buffer handling issues can be found.

@zmike zmike added the bug label Jun 2, 2022
@kovidgoyal
Copy link
Owner

resizing kitty windows works perfectly fine under GNOME, KDE, SWAY (for
floating windows). I'm afraid I dont have any interest in Weston.
Patches welcome.

@fooishbar
Copy link

It should be reasonably straightforward: don't destroy a wl_buffer until the release event has arrived. Otherwise you're forcing the compositor to do an allocation & copy for you, which is suboptimal.

@kovidgoyal
Copy link
Owner

Except this is Wayland. Changing something like destruction order will
break some other corner case on some other compositor and even if it
doesn't, making such a change means testing ten different
compositors+versions. Waaaaay too much effort for the payoff.

Not to mention that the entire codebase has only 3 calls to
wl_buffer_destroy, one for mouse cursor and two for client side
decorations. The problem as I understand it has to do with drawing
the window surface not CSD or mouse cursors, and the window surface is
drawn via OpenGL. So presumably something would need to be changed in
whatever piece of code is responsible for bridging OpenGL to Wayland.
That code isnt in kitty however.

@fooishbar
Copy link

No, it's the client-side decorations, not GL.

Changing kitty from its current behaviour of violating the spec (destroying buffers before the release event arrives) to new behaviour of not violating the spec (waiting until after the release event arrives) is risk-free.

@kovidgoyal
Copy link
Owner

Ah, client side decorations, the best thing since sliced bread. I dont understand why destroying a CSD surface should cause flickering in rendering of the main window surface but I will take your word for it. I will say however, that I get no flickering resizing kitty windows on weston with kitty 0.25.1 and weston 10.0.0.

@fooishbar
Copy link

It doesn’t make the main surface flicker, but the decorations do constantly flicker to black. This is caused by the wl_buffers being immediately destroyed when new ones are created; you need to listen for the wl_buffer release event and defer destruction until they are unused.

@kovidgoyal
Copy link
Owner

kovidgoyal commented Jun 3, 2022 via email

@kovidgoyal kovidgoyal reopened this Jun 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants