Currently, the rendering path required creating a texture for each path,
which wasted a large amount of video memory. In our application, simply
drawing some charts resulted in video memory usage as high as 5G.
I removed the step of creating path textures and directly drew the paths
on the rendering target, adding post-processing global multi-sampling
anti-aliasing. Drawing paths no longer requires allocating any
additional video memory and also improves the performance of path
rendering.
Release Notes:
- N/A
---------
Co-authored-by: Jason Lee <huacnlee@gmail.com>
Implements a chunking strategy for the element arena that allows it to
grow dynamically based on allocations, it is initialised with a single
chunk of a total size of 1 mebibyte. On allocation of data with a size
greater than the remaining space of the current chunk a new chunk is
created.
This reduces the memory allocation from the static 32 mebibytes, this
especially helps GPUI applications that don't need such a large element
arena and even Zed in most cases. This also prevents the panic when
allocations ever exceed the element arena.
Release Notes:
- N/A
---------
Co-authored-by: Michael Sloan <michael@zed.dev>
This is an easy way to shave some microseconds off the critical path for
frame rendering. On my machine this reduces typical frame rendering
latency by ~100 microseconds, probably quite a bit more on slower
machines.
Here is how long it typically takes to drop elements from the arena,
from a fairly brief run:
Release Notes:
- N/A
For me this is a panic that started occurring today in my use of Zed.
The repro is to type `ctrl-x` to start a pending key sequence and then
close the collab side panel with the mouse. The issue is that
dispatching the action based on pending keystrokes uses the same
`DispatchNodeId` as when the 1 second timer was started.
`DispatchNodeId` is not stable across frames. This also means that the
wrong `DispatchNodeId` can be used in the non-panicing case, potentially
causing the action to not occur.
The mystery here is why did this only start happening now in my use of
Zed, and why isn't it showing up in the panics dashboard / issue
reports.
Panic looks like
```
{
"thread": "main",
"payload": "index out of bounds: the len is 467 but the index is 1861",
"location_data": {
"file": "crates/gpui/src/key_dispatch.rs",
"line": 519
},
"backtrace": [
"zed::reliability::init_panic_hook::{{closure}}::he1d8257b19b16eec+155265758",
"std::panicking::rust_panic_with_hook::h33b18b24045abff4+128544307",
"std::panicking::begin_panic_handler::{{closure}}::hf8313cc2fd0126bc+128543530",
"std::sys::backtrace::__rust_end_short_backtrace::h57fe07c8aea5c98a+128537145",
"__rustc[95feac21a9532783]::rust_begin_unwind+128542669",
"core::panicking::panic_fmt::hd54fb667be51beea+9456688",
"core::panicking::panic_bounds_check::h1a9bf3d94de0fc80+9457170",
"gpui::key_dispatch::DispatchTree::dispatch_path::hce77d277881569bf+73992023",
"gpui::app::App::spawn::{{closure}}::hb1e79bbbdead3012+73687056",
"async_task::raw::RawTask<F,T,S,M>::run::hd13f66f99bb24bbd+70694231",
"<gpui::platform::linux::x11::client::X11Client as gpui::platform::linux::platform::LinuxClient>::run::h5a92ddaaf9a06dd1+74465138",
"gpui::platform::linux::platform::<impl gpui::platform::Platform for P>::run::hd19ac52b2d94268e+74064525",
"gpui::app::Application::run::hee83110c717a5af0+151862692",
"zed::main::hca7e2265584c4139+153307630",
"std::sys::backtrace::__rust_begin_short_backtrace::h2e04f4034c2d82c5+153146899",
"std::rt::lang_start::{{closure}}::h91cf1ca0eeae23ae+154454121",
"std::rt::lang_start_internal::h418648f91f5be3a1+128467809",
"main+153326748",
"__libc_start_call_main+25056432783818",
"__libc_start_main_impl+25056432784011",
"_start+12389486"
],
"app_version": "0.190.6",
"app_commit_sha": "9a2dcbbe24",
"release_channel": "stable",
"target": "x86_64-unknown-linux-gnu",
"os_name": "Linux X11",
"os_version": "ubuntu 24.04",
"architecture": "x86_64",
"panicked_on": 1750185799233,
"system_id": "abae7201-61fb-442b-922b-202071ae81c0",
"installation_id": "69a0fb9a-11a2-4065-ad8c-b281e68525ad",
"session_id": "bc5b5f2f-e4c3-44a8-948e-c0550a2e2ef2"
}
```
Release Notes:
- Fixed a rare panic / potential incorrect action dispatch when a
pending keysequence is applied after the 1 second timer elapsing.
Closes#21700
Release Notes:
- Added caps lock support and show a warning if the user is entering an
SSH password with Caps Lock enabled
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
Co-authored-by: 张小白 <364772080@qq.com>
Closes#32592
Follow-up to #31965
This PR fixes the cursor style flickering on Linux systems. The issue
arose since the window cursor style was not reused anymore for
subsequent frames after the changes in #31965. This works on MacOS for
hiding cursors, since they are hidden until the next mouse movement
occurs, which is not the case for other systems.
This PR re-adds this whilst keeping the fixes applied in #31965. We now
determine the first cursor style that is hovered and continue searching
for a cursor style that should be applied globally. If one to apply for
the whole window is found, we return that cursor style early instead.
Alternatively, we could store window cursor style request in a vector
similar to normal cursor styles. That would require more memory in
exchange for fewer checks which cursor style to apply. I preferred the
approach here, though, but can change this should the other method be
preferred.
CC @smitbarmase since you assigned yourself that issue.
Release Notes:
- Fixed an issue where the cursor would flicker whilst typing.
Follow-up to #24797
This PR ensures some cursor styles do not change for draggable elements
during dragging. The linked PR covered this on the higher level for
draggable divs. However, e.g. the pane divider inbetween two editors is
not a draggable div and thus still has the issue that the cursor style
changes during dragging. This PR fixes this issue by setting the hitbox
to `None` in cases where the element is currently being dragged, which
ensures the cursor style is applied to the cursor no matter what during
dragging.
Namely, this change fixes this for
- non-div pane dividers
- minimap slider and the
- editor scrollbars
and implements it for the UI scrollbars (Notably, UI scrollbars do
already have `cursor_default` on their parent container but would not
keep this during dragging. I opted out on removing this from the parent
containers until #30194 or a similar PR is merged).
https://github.com/user-attachments/assets/f97859dd-5f1d-4449-ab92-c27f2d933c4a
Release Notes:
- N/A
Fixes: #29812Fixes: #22538
Co-Authored-By: <corentinhenry@gmail.com>
Release Notes:
- vim: Multi-key bindings in insert mode will now show the pending
keystroke in the buffer. For example if you have `jk` mapped to escape,
pressing `j` will immediately show a `j`.
Allows setting element as window control elements which consist of
`Drag`, `Close`, `Max`, or `Min`. This allows you to implement
dynamically sized elements that control the platform window, this is
used for areas such as the title bar. Currently only implemented for
Windows.
Release Notes:
- N/A
Fixes two things:
* ~3 months ago [in PR
#26420](https://github.com/zed-industries/zed/pull/26420/files#diff-33b58aa2da03d791c2c4761af6012851b7400e348922d64babe5fd48ac2a8e60)
`bindings_for_action` was changed to return bindings even when they are
shadowed (when the keystrokes would actually do something else).
* For edit prediction keybindings there was some odd behavior where
bindings for `edit_prediction_conflict` were taking precedence over
bindings for `edit_prediction` even when the `edit_prediction_conflict`
predicate didn't match. The workaround for this was #24812. The way it
worked was:
- List all bindings for the action
- For each binding, get the highest precedence binding with the same
input sequence
- If the highest precedence binding has the same action, include this
binding. This was the bug - this meant that if a binding in the keymap
has the same keystrokes and action it can incorrectly take display
precedence even if its context predicate does not pass.
- Fix is to check that the highest precedence binding is a full match.
To do this efficiently, it's based on an index within the keymap
bindings.
Also adds `highest_precedence_binding_*` variants which avoid the
inefficiency of building lists of bindings just to use the last.
Release Notes:
- Fixed display of keybindings to skip bindings that are shadowed by a
binding that uses the same keystrokes.
- Fixed display of `editor::AcceptEditPrediction` bindings to use the
normal precedence that prioritizes user bindings.
This PR implements the previously unimplemented window_handle and
display_handle methods in the wayland platform. It also exposes the
display_handle method through the Window struct.
Release Notes:
- N/A
Closes#16527
Release Notes:
- Added MacOS titlebar double-click action
---
Unfortunately, Apple doesn't seem to make the "Fill" API public or
documented anywhere.
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
Release Notes:
- N/A
----
The before version GPUI used `Cancel` for cancel text, if we use
non-English text (e.g.: "取消" in Chinese), then the press `Esc` to cancel
will not work.
So this PR to change it by use `PromptButton` to instead the `&str`,
then we can use `PromptButton::cancel("取消")` for the `Cancel` button.
Run `cargo run -p gpui --example window` to test.
---
Platform Test:
- [x] macOS
- [x] Windows
- [x] Linux (x11 and Wayland)
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
tl;dr: This adds `.block_mouse_except_scroll()` which should typically
be used instead of `.occlude()` for cases when the mouse shouldn't
interact with elements drawn below an element. The rationale for
treating scroll events differently:
* Mouse move / click / styles / tooltips are for elements the user is
interacting with directly.
* Mouse scroll events are about finding the current outer scroll
container.
Most use of `occlude` should probably be switched to this, but I figured
I'd derisk this change by minimizing behavior changes to just the 3 uses
of `block_mouse_except_scroll`.
GPUI changes:
* Added `InteractiveElement::block_mouse_except_scroll()`, and removes
`stop_mouse_events_except_scroll()`
* Added `Hitbox::should_handle_scroll()` to be used when handling scroll
wheel events.
* `Window::insert_hitbox` now takes `HitboxBehavior` instead of
`occlude: bool`.
- `false` for that bool is now `HitboxBehavior::Normal`.
- `true` for that bool is now `HitboxBehavior::BlockMouse`.
- The new mode is `HitboxBehavior::BlockMouseExceptScroll`.
* Removes `Default` impl for `HitboxId` since applications should not
manually create `HitboxId(0)`.
Release Notes:
- N/A
Editing JSON styles is not very helpful for bringing style changes back
to the actual code. This PR adds a buffer that pretends to be Rust,
applying any style attribute identifiers it finds. Also supports
completions with display of documentation. The effect of the currently
selected completion is previewed. Warning diagnostics appear on any
unrecognized identifier.
https://github.com/user-attachments/assets/af39ff0a-26a5-4835-a052-d8f642b2080c
Adds a `#[derive_inspector_reflection]` macro which allows these methods
to be enumerated and called by their name. The macro code changes were
95% generated by Zed Agent + Opus 4.
Release Notes:
* Added an element inspector for development. On debug builds,
`dev::ToggleInspector` will open a pane allowing inspecting of element
info and modifying styles.
Open inspector with `dev: toggle inspector` from command palette or
`cmd-alt-i` on mac or `ctrl-alt-i` on linux.
https://github.com/user-attachments/assets/54c43034-d40b-414e-ba9b-190bed2e6d2f
* Picking of elements via the mouse, with scroll wheel to inspect
occluded elements.
* Temporary manipulation of the selected element.
* Layout info and JSON-based style manipulation for `Div`.
* Navigation to code that constructed the element.
Big thanks to @as-cii and @maxdeviant for sorting out how to implement
the core of an inspector.
Release Notes:
- N/A
---------
Co-authored-by: Antonio Scandurra <me@as-cii.com>
Co-authored-by: Marshall Bowers <git@maxdeviant.com>
Co-authored-by: Federico Dionisi <code@fdionisi.me>
https://github.com/zed-industries/zed/issues/30972 brought up another
case where our context is not enough to track the actual source of the
issue: we get a general top-level error without inner error.
The reason for this was `.ok_or_else(|| anyhow!("failed to read HEAD
SHA"))?; ` on the top level.
The PR finally reworks the way we use anyhow to reduce such issues (or
at least make it simpler to bubble them up later in a fix).
On top of that, uses a few more anyhow methods for better readability.
* `.ok_or_else(|| anyhow!("..."))`, `map_err` and other similar error
conversion/option reporting cases are replaced with `context` and
`with_context` calls
* in addition to that, various `anyhow!("failed to do ...")` are
stripped with `.context("Doing ...")` messages instead to remove the
parasitic `failed to` text
* `anyhow::ensure!` is used instead of `if ... { return Err(...); }`
calls
* `anyhow::bail!` is used instead of `return Err(anyhow!(...));`
Release Notes:
- N/A
This PR fixes several possible memory leaks due to loading images in
markdown files and the image viewer, using the new image cache APIs
TODO:
- [x] Ensure this didn't break rendering in any of the affected
components.
Release Notes:
- Fixed several image related memory leaks
cc @notpeter
Before this change we used our own copy of `cx.key_context()` when
matching.
This led to races where the context queried could be either before (or
after) the
context used in dispatching.
To avoid the race, gpui now passes out the context stack actually used
instead.
Release Notes:
- Fixed a bug where the Key Context View could show the incorrect
context,
causing confusing results.
cc: @sunli829 @huacnlee @probably-neb
I really liked the earlier PR, but had an idea for how to utilize the
element state so that you don't need to construct the cache externally.
I've updated the APIs to introduce an `ImageCacheProvider` trait, and
added an example implementation of it to the image gallery :)
Release Notes:
- N/A
Closes#27414
`ImageCache` is independent of the original image loader and can
actively release its cached images to solve the problem of images loaded
from the network or files not being released.
It has two constructors:
- `ImageCache::new`: Manually manage the cache.
- `ImageCache::max_items`: Remove the least recently used items when the
cache reaches the specified number.
When creating an `img` element, you can specify the cache object with
`Img::cache`, and the image cache will be managed by `ImageCache`.
In the example `crates\gpui\examples\image-gallery.rs`, the
`ImageCache::clear` method is actively called when switching a set of
images, and the memory will no longer continuously increase.
Release Notes:
- N/A
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
Closes#23449
Release Notes:
- Fixed a bug causing shift to get stuck down when the window focus
changes
---------
Co-authored-by: Dino <dinojoaocosta@gmail.com>
Swift bindings BEGONE
Release Notes:
- Switched from using the Swift LiveKit bindings, to the Rust bindings,
fixing https://github.com/zed-industries/zed/issues/9396, a crash when
leaving a collaboration session, and making Zed easier to build.
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Co-authored-by: Michael Sloan <michael@zed.dev>
Closes#4461
Take 2 on https://github.com/zed-industries/zed/pull/25040.
Fixes panic caused due to using `setHiddenUntilMouseMoves` return type
to `set` cursor on macOS.
Release Notes:
- Now cursor hides when the user is typing in editor. It will stay
hidden until it is moved again. This behavior is `true` by default, and
can be configured with `hide_mouse_while_typing` in settings.
---------
Co-authored-by: Peter Tripp <peter@zed.dev>
Co-authored-by: Thomas Mickley-Doyle <thomas@zed.dev>
Co-authored-by: Agus <agus@zed.dev>
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Co-authored-by: Agus Zubiaga <hi@aguz.me>
Co-authored-by: Angelk90 <angelo.k90@hotmail.it>
This seems more correct as corners are not necessarily only for rounding
radii.
Also applies clamping after scaling in `paint_quad`, deduplicating that
logic. This also provides a more precise result by doing the clamping
after scaling, avoiding floating point rounding issues (probably a
non-issue).
Release Notes:
- N/A
Features:
* Scales dash spacing with border width.
* Laying out dashes around rounded corners.
* Varying border widths with rounded corners - now uses an ellipse for the inner edge of the border.
* When there are no rounded corners, each straight border is laid out separately, so that the dashes to meet at the corners.
* All sides of each dash are antialiased.
Release Notes:
- N/A
---------
Co-authored-by: Michael Sloan <michael@zed.dev>
Co-authored-by: Ben <ben@zed.dev>
This is the core change:
https://github.com/zed-industries/zed/pull/26758/files#diff-044302c0d57147af17e68a0009fee3e8dcdfb4f32c27a915e70cfa80e987f765R1052
TODO:
- [x] Use AsyncFn instead of Fn() -> Future in GPUI spawn methods
- [x] Implement it in the whole app
- [x] Implement it in the debugger
- [x] Glance at the RPC crate, and see if those box future methods can
be switched over. Answer: It can't directly, as you can't make an
AsyncFn* into a trait object. There's ways around that, but they're all
more complex than just keeping the code as is.
- [ ] Fix platform specific code
Release Notes:
- N/A
This reverts commit a8610fbd13.
I've been seeing some reports of segmentation faults that appear to
point to this change as the culprit.
Closes#25366.
Release Notes:
- Community: Reverted #25040, so remove the corresponding entry from the
release notes.
Closes https://github.com/zed-industries/zed/issues/4461
This PR improves the coding experience by hiding the mouse while the
user is typing so it does not accidentally get in their way, making it
challenging to ready characters in the editor.
Release Notes:
- The following PR hides the cursor when the user is typing by adding a
new cursor style called `None`.
- Assuming the user does not move the mouse, it will stay hidden until
it is moved again.
https://github.com/user-attachments/assets/6ba9f2ee-b9f3-4595-81e4-e9d986da4a39
---------
Co-authored-by: Agus <agus@zed.dev>
Co-authored-by: Peter Tripp <peter@zed.dev>
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Implement `raw_window_handle::HasWindowHandle` for `gpui::Window`
This opens a lot of possibility of using gpui with platform specific
APIs.
Edit: With this exposed, we can use crates like `window-vibrancy`,
`muda` (menus crate) or even use `wry` (a webview renderer) to create a
child `WebView` inside the gpui window.
Release Notes:
- N/A
This long standing bug was caused by `Pane`'s focus_in handler bouncing
the focus to another handle.
Because focus resolution happens _after_ a frame has been rendered, the
only way to deal with this case is to schedule another frame to be
redrawn. However, we where suppressing all window refreshes that occur
during a focus transfer, causing this focus change to be completely
missed. However, changing this behavior can lead to infinite notify
loops, due to drawing a frame causing another to be rendered.
This PR fixes this problem narrowly by adding an `on_next_frame()`
callback in the pane's focus handle, so that the focus changes take
effect almost immediately. But only for this case, where we know it
doesn't cause infinite notify loops.
TODO:
- [x] Fix the infinite notify loop bug or determine a third way to fix
this lag
Release Notes:
- Fixed a bug where shifting focus to the terminal panel could be slow
Chatted with @as-cii about limitations in the `Window::parent_view_id()`
API (see:
https://github.com/zed-industries/zed/pull/24182/commits/662153dcfdd80804f4041761c09c4a309d79f6d4)
and realized that I shouldn't be using the dispatch tree's data
structures as they are layout dependent. I've introduced a new stack to
`Window`, `rendered_entity_stack`, that tracks exactly which view's
elements are being drawn. As such, I've also been able to remove the
`Option<>` around the previous API.
Release Notes:
- N/A
We think this could fix issues around view invalidation during focus
handling.
I want to run CI on this and see.
cc @mikayla-maki @maxbrunsfeld
Release Notes:
- N/A
