Slow start on labwc

[AdamNiederer]

To Reproduce

1. Run an unconfigured labwc and terminal from a tty with labwc -C none -s xterm (can be any term including kitty)
2. From that terminal, run kitty with kitty --config none
3. Observe that the kitty window is created after ~250ms, but the terminal prompt does not appear for another ~250ms.
4. Further observe that all keyboard input before the display of the terminal prompt is dropped

This is an issue because it eats the first few characters of the command I want to run after opening a terminal

This delay does not occur on openbox, nor on labwc by using XWayland: env -u WAYLAND_DISPLAY kitty --config none, which reduces the startup time to just the ~250ms required to show the window; there is no delay between window showing and prompt showing.

I have reproduced this issue on the following two systems:

• Laptop with 6900HX, 680M, 3070ti and hybrid graphics enabled
• Desktop with 12600k, 7900XT and no hybrid graphics setup

Screenshots

A recording of this bug in action; the second time, I am typing "abcdef" after invoking kitty to demonstrate the late input capture

kitty-startup-delay.webm

Environment Details

labwc 0.7.2

kitty 0.35.1 created by Kovid Goyal
Linux 6.9.3-arch1-1 #1 SMP PREEMPT_DYNAMIC Fri, 31 May 2024 15:14:45 +0000 x86_64

Arch Linux 6.9.3-arch1-1 (/dev/tty)

Running under: Wayland (labwc 0.7.2) missing: preferred_scale
OpenGL: '4.6 (Core Profile) Mesa 24.1.1-arch1.1' Detected version: 4.6
Frozen: False
Paths:
  kitty: /usr/bin/kitty
  base dir: /usr/lib/kitty
  extensions dir: /usr/lib/kitty/kitty
  system shell: /bin/bash

Config options different from defaults:

Important environment variables seen by the kitty process:
  PATH                                /usr/local/bin:/usr/bin:/bin:/usr/local/sbin:
  LANG                                en_US.UTF-8
  EDITOR                              emacs
  SHELL                               /bin/bash
  DISPLAY                             :0
  WAYLAND_DISPLAY                     wayland-0
  USER                                adam
  XDG_SESSION_PATH                    /org/freedesktop/DisplayManager/Session0
  XDG_SEAT                            seat0
  XDG_SESSION_DESKTOP                 labwc
  XDG_SESSION_TYPE                    wayland
  XDG_GREETER_DATA_DIR                /var/lib/lightdm-data/adam
  XDG_CURRENT_DESKTOP                 wlroots
  XDG_SEAT_PATH                       /org/freedesktop/DisplayManager/Seat0
  XDG_SESSION_CLASS                   user
  XDG_VTNR                            7
  XDG_SESSION_ID                      9
  XDG_RUNTIME_DIR                     /run/user/1000

Additional Context

It would be great if either kitty captured keyboard input sooner, so the delay doesn't eat the first chars of a command, or the delay between showing the window and prompt could be reduced without XWayland. Ideally it'd be able to capture input immediately after invocation, but I'm not sure if that's possible.

[kovidgoyal]

This will be because labwc is taking forever to send the fractional
scale to kitty after window creation. The child program is only started
on Wayland after the compositor sends the fraction and preferred integer
scales to avoid a window resize during child startup. This is
fundamentally because of Wayland's poor design, but most other
compositors manage this fast enough that it is not noticeable. Either
use a better compositor or report the issue to labwc. You can get
timings for all tihs by running kitty with --debug-rendering

[AdamNiederer]

I have reported the issue to labwc and they have posted a response in the linked issue: labwc/labwc#1914 - I haven't looked at the code for either, but I would agree with them that awaiting an asynchronous event before first paint and first capture of input might be best avoided if at all possible.

[kovidgoyal]

Except that kitty does not wait forever it waits for 250 ms max and it does
so for a very good reason. Namely that many non shell command line
programs misbehave when getting SIGWINCH during startup and kitty unlike
most terminal emulators encourages usage of such programs directly
rather than going through a shell first. I am not going to change this to
accommodate one errant Wayland compositor. Indeed, the idea that this
needs to be asynchronous at all is bonkers, but lets not go there, it's
par for the course with Wayland.

[kovidgoyal]

Oh and I took the time to build labwc to see what its actually doing by running kitty with --debug-rendering as I suggested above. And its sending the fractional scale fast enough (in about 30ms), it's never sending the preferred integer buffer scale. kitty waits for a complex combination of both.

Of course, some compositors send fractional scales of 1 before actually configuring and the correct scale after configuring once (hyprland for example), so kitty currently doesnt assume the compositor is done playing around until after fractional scale is set to non 1 value or the window is configured once or the preferred buffer scale is set. This logic will lead to a 250ms wait on labwc with fractional scale of 1 since fractional scale is sent before the configure event and no preferred scale event is sent.

Sigh, Wayland...

[kovidgoyal]

Ola

[Consolatis]

And to top it off it appears to
have no way for the user to set/control the scale so I cant even test
what it will do with fractional scales other than 1. Sigh. As with all
things Wayland, you need to be a masochist to subject yourself to them.

Dunno, you could use any client that supports the output management protocol, for example wlr-randr or wdisplays.

[kovidgoyal]

On Sun, Jun 16, 2024 at 02:54:39AM -0700, Consolatis wrote: > And to top it off it appears to have no way for the user to set/control the scale so I cant even test what it will do with fractional scales other than 1. Sigh. As with all things Wayland, you need to be a masochist to subject yourself to them. Dunno, you could use any client that supports the output management protocol, for example `wlr-randr` or `wdisplays`.

Thanks, since I dont use Wayland I dont have a clue about such things. So, you are saying, labwc lacks a way to actually *configure before it runs* as opposed to *change at runtime after it runs* the scale of an output? I suppose that's good enough to test things for me, which is all I care about. Will make my test script that runs labwc run that command too on startup. Sigh.

[Consolatis]

labwc lacks a way to actually *configure before it runs* as opposed to *change at runtime after it runs* the scale of an output?

Right, if you want to persist some config you can use kanshi instead. But for testing wlr-randr is usually enough (and should work for any wlroots based compositor).