A single field observation on Ubuntu 22.04: the very first time a pane was carried as a wisp in a session, there was a pause of roughly two seconds before the wisp appeared; every later drag in the same session was immediate. macOS does not show this.
Status: unconfirmed. This has been observed once and has not yet been reproduced under controlled conditions. One plausible explanation is first-use GPU pipeline/surface creation being slower on the Linux driver stack than on Metal, but that is a hypothesis, not an established cause. Treat the description, the timing, and the explanation as needing validation.
If you can reproduce this, please add:
- Distro, GPU, and driver (Mesa/proprietary, version)
- X11 or Wayland
- Whether the stall happens on the first drag only, or recurs
- Rough duration, and whether the app stays responsive during it
Validation plan
Time the first-wisp path on a Linux box (window + surface + pipeline creation) and compare against subsequent drags. If the cold-start cost is confirmed, pre-warming the wisp renderer at startup or when a drag arms is the likely fix.
A single field observation on Ubuntu 22.04: the very first time a pane was carried as a wisp in a session, there was a pause of roughly two seconds before the wisp appeared; every later drag in the same session was immediate. macOS does not show this.
Status: unconfirmed. This has been observed once and has not yet been reproduced under controlled conditions. One plausible explanation is first-use GPU pipeline/surface creation being slower on the Linux driver stack than on Metal, but that is a hypothesis, not an established cause. Treat the description, the timing, and the explanation as needing validation.
If you can reproduce this, please add:
Validation plan
Time the first-wisp path on a Linux box (window + surface + pipeline creation) and compare against subsequent drags. If the cold-start cost is confirmed, pre-warming the wisp renderer at startup or when a drag arms is the likely fix.