Skip to content

Conversation

@MrSubidubi
Copy link
Member

Closes #39172

This refactors when we resolve UI keybindings in an effort to reduce flickering whilst painting these: Previously, we would always resolve these upon creating the binding. This could lead to cases where the corresponding context was not yet available and no binding could be resolved, even if the binding was then available on the next presented frame. Following that, on the next rerender of whatever requested this keybinding, the keybind for that context would then be found, we would render that and then also win a layout shift in that process, as we went from nothing rendered to something rendered between these frames.

With these changes, this now happens less often, because we only look for the keybinding once the context can actually be resolved in the window.

Before After
https://github.com/user-attachments/assets/adebf8ac-217d-4c7f-ae5a-bab3aa0b0ee8 https://github.com/user-attachments/assets/70a82b4b-488f-4a9f-94d7-b6d0a49aada9

Also reduced cloning in the keymap editor in this process, since that requiered changing due to this anyway.

Release Notes:

  • Fixed some cases where keybinds would appear with a slight delay, causing a flicker in the process
@cla-bot cla-bot bot added the cla-signed The user has signed the Contributor License Agreement label Oct 22, 2025
@MrSubidubi MrSubidubi enabled auto-merge (squash) October 22, 2025 19:04
@MrSubidubi MrSubidubi merged commit f393138 into main Oct 22, 2025
21 checks passed
@MrSubidubi MrSubidubi deleted the keybind-jank branch October 22, 2025 19:52
lidm0707 pushed a commit to lidm0707/zed that referenced this pull request Oct 23, 2025
Closes zed-industries#39172

This refactors when we resolve UI keybindings in an effort to reduce
flickering whilst painting these: Previously, we would always resolve
these upon creating the binding. This could lead to cases where the
corresponding context was not yet available and no binding could be
resolved, even if the binding was then available on the next presented
frame. Following that, on the next rerender of whatever requested this
keybinding, the keybind for that context would then be found, we would
render that and then also win a layout shift in that process, as we went
from nothing rendered to something rendered between these frames.

With these changes, this now happens less often, because we only look
for the keybinding once the context can actually be resolved in the
window.

| Before | After | 
| --- | --- |
|
https://github.com/user-attachments/assets/adebf8ac-217d-4c7f-ae5a-bab3aa0b0ee8
|
https://github.com/user-attachments/assets/70a82b4b-488f-4a9f-94d7-b6d0a49aada9
|

Also reduced cloning in the keymap editor in this process, since that
requiered changing due to this anyway.

Release Notes:

- Fixed some cases where keybinds would appear with a slight delay,
causing a flicker in the process
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cla-signed The user has signed the Contributor License Agreement

2 participants