With `send_and_check_request` we'd be blocking both the main loop and
the caller. `send_request` is only going to be blocking on the main loop
when processing the request.
Release Notes:
- N/A
Based on a flamegraph from `perf`/`hotspot`, we are spending 40% of time
redrawing, another 40% of time downloading stuff (i.e. rust toolchain),
and the rest on text rendering, layout and such. This is with Vulkan
Validation (see https://github.com/zed-industries/zed/pull/8044).
I'm also wondering if it would be better with #7758, but regardless we
should have no problem rendering at 60-120 fps and processing user
input. More follow-ups are expected here.
This PR enables server side decorations on Wayland if possible. This is
stopgap solution, so that the window can be moved, resized and dragged
on Wayland sessions at all.
Since Wayland compositors can decide to force either mode (as in,
forcing server or client side decorations), this requires additional
handling in zed. Since zed doesn't provide any of that handling as of
now, as a temporary solution server side decorations are always
requested.
Closes#7973
This fixes a leak in GPUI when the user didn't override
`on_should_close_window`.
Release Notes:
- N/A
---------
Co-authored-by: Thorsten <thorsten@zed.dev>
Release Notes:
- N/A
---
Right now the Wayland backend is using `xkb::State::key_get_utf8` as the
`key`, when it should be used as the `ime_key`. It also manages
pressing/releasing modifiers manually when this should be managed by the
display server.
This allows modifier combinations to work in more cases, making it an
alternative to https://github.com/zed-industries/zed/pull/7975, which
interprets what is now only used as the `ime_key` value as a `key`
value.
Generally the BladeAtlas logic has been deferring all the texture
initializations and updates till `begin_frame`. This doesn't work for
path rasterization, since a texture needs to be allocated after
`begin_frame` and used immediately.
Fixed validation error:
> UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout(ERROR / SPEC):
msgNum: 1303270965 - Validation Error: [
UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout ] Object 0:
handle = 0x60ce301b9010, name = main, type =
VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0x51820000000007b,
name = atlas, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x4dae5635 |
vkQueueSubmit(): pSubmits[0].pCommandBuffers[0] command buffer
VkCommandBuffer 0x60ce301b9010[main] expects VkImage
0x51820000000007b[atlas] (subresource: aspectMask 0x1 array layer 0, mip
level 0) to be in layout VK_IMAGE_LAYOUT_GENERAL--instead, current
layout is VK_IMAGE_LAYOUT_UNDEFINED.
Objects: 2
[0] 0x60ce301b9010, type: 6, name: main
[1] 0x51820000000007b, type: 10, name: atlas
Release Notes:
- N/A
Adds initial keyboard and mouse input for Wayland (thanks to @gabydd and
@kvark for reference).
Release Notes:
- N/A
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
Depends on https://github.com/zed-industries/font-kit/pull/2 and
https://github.com/kvark/blade/pull/77
This change enables Blade to be also used on MacOS. It will also make it
easier to use it on Windows.
What works: most of the things. Zed loads as fast and appears equally
responsive to the current renderer.
<img width="306" alt="Screenshot 2024-02-11 at 12 09 15 AM"
src="https://github.com/zed-industries/zed/assets/107301/66d82f45-5ea2-4e2b-86c6-5b3ed333c827">
Things missing:
- [x] video streaming. ~~Requires a bit of plumbing on both Blade and
Zed sides, but all fairly straightforward.~~
- verified with a local setup
- [x] resize. ~~Not sure where exactly to hook up the reaction on the
window size change. Once we know where, the fix is one line.~~
- [ ] fine-tune CA Layer
- this isn't a blocker for merging the PR, but it would be a blocker if
we wanted to switch to the new path by default
- [ ] rebase on latest, get the dependency merged (need review/merge of
https://github.com/zed-industries/font-kit/pull/2!)
Update: I implemented resize support as well as "surface" rendering on
the Blade path (which will be useful on Linux/Windows later on). I
haven't tested the latter though - not sure how to get something
streaming. Would appreciate some help! I don't think this should be a
blocker to this PR, anyway.
The only little piece that's missing for the Blade on MacOS path to be
full-featured is fine-tuning the CALayer configuration. Zed does a lot
of careful logic in configuring the layer, such as switching the
"present with transaction" on/off intermittently, which Blade path
doesn't have yet.
Release Notes:
- N/A
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
Per https://github.com/zed-industries/zed/pull/7814, this is more
trouble than it's worth. As these functions are never exposed to the
user of GPUI, we can just manually audit and enforce the relevant rules.
Release Notes:
- N/A
When a view is invalidated, we want to participate in Taffy layout with
an accurate style rather than the dummy style we use when a view is
cached. Previously, we only detected invalidation during paint. This
adds logic to layout as well to avoid using the dummy style when dirty.
Release Notes:
- N/A
---------
Co-authored-by: Nathan <nathan@zed.dev>
This PR removes the `full` style method and replaces it with
`size_full`, as the two do the same thing.
This is the generated code for `size_full`:
```rs
#[doc = "Sets the width and height of the element.\n\n100%"]
fn size_full(mut self) -> Self {
let style = self.style();
style.size.width = Some((gpui::relative(1.)).into());
style.size.height = Some((gpui::relative(1.)).into());
self
}
```
Release Notes:
- N/A
Upgraded Taffy to v0.4.0 from crates.io (previously using prerelease
version from git).
Code changes required were minor as gpui was already using a recent
version of Taffy.
Release Notes:
- N/A
This PR adds Wayland support to gpui using
[wayland-rs](https://github.com/Smithay/wayland-rs). It is based on
[#7598](https://github.com/zed-industries/zed/pull/7598).
It detects Wayland support at runtime by checking the existence of the
`WAYLAND_DISPLAY` environment variable. If it does not exist or is
empty, the X11 backend will be used. To use the X11 backend in a Wayland
session (for development purposes), you just need to unset
WAYLAND_DISPLAY (`WAYLAND_DISPLAY= cargo run ...`).
At the moment it only creates the window and renders the initial content
provided by `BladeRenderer`, so it can run "Hello world" example.
Todo:
- [x] Add basic Wayland support.
- [x] Add window resizing.
- [x] Add window closing.
- [x] Add window updating.
- [ ] Implement input handling, fractional scaling, and support other
Wayland protocols.
- [ ] Implement all unimplemented todo!(linux).
- [ ] Add window decorations or use custom decorations (like on MacOS).
- [ ] Address other missing functionality.
Release Notes:
- N/A
---------
Co-authored-by: gabydd <gabydinnerdavid@gmail.com>
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
Alternative to #7758, which doesn't involve adding a new trait method
`request_draw`.
Somehow, my whole screen goes blinking black with this when moving the
window, so not ready for landing.
Release Notes:
- N/A
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
We see some panics in the Drop handler for MacWindow
Looking into this, I noticed that our drop implementation was not
correctly
cleaning up the window state.
Release Notes:
- N/A
Fixes#4712, or at least works around it. As discussed in the issue,
setting the buttons frames while fullscreen can cause them to render
in the wrong location. This fixes that by simply not moving them when
fullscreen.
Release Notes:
- Separated Linux platform and X11-specific code, so that we can add
Wayland support now.
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
Fix found by @h3mosphere (thanks!)
Solves the Vulkan validation on start on some platforms about the
mismatched surface size, e.g.
```
VUID-VkSwapchainCreateInfoKHR-imageExtent-01274(ERROR / SPEC): msgNum: 2094043421 - Validation Error: [ VUID-VkSwapchainCreateInfoKHR-imageExtent-01274 ] Object 0: handle = 0x55dff99554c0, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x7cd0911d | vkCreateSwapchainKHR() called with imageExtent = (1920,1080), which is outside the bounds returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR(): currentExtent = (1920,1016), minImageExtent = (1920,1016), maxImageExtent = (1920,1016). The Vulkan spec states: imageExtent must be between minImageExtent and maxImageExtent, inclusive, where minImageExtent and maxImageExtent are members of the VkSurfaceCapabilitiesKHR structure returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR for the surface (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-VkSwapchainCreateInfoKHR-imageExtent-01274)
```
Release Notes:
- N/A
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
Before the change to `script/clippy`, bash ignored first `clippy`
invocation failure and CI moved on with Linux errors and warnings
emitted.
Release Notes:
- N/A
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
On macOS, this will enable or disable the Metal HUD at runtime. Note
that this only works when Zed is bundled because it requires to set the
`MetalHudEnabled` key in the Info.plist.
Release Notes:
- Added a new `ToggleGraphicsProfiler` command that can be used as an
action (or via the `Help -> Toggle Graphics Profiler` menu) to
investigate graphics performance.
Previously we wouldn't handle Backspace in dead key state correctly:
instead of removing what was typed, we'd insert the text that was in the
dead key state.
Example: on a US English layout, press `opt-u` to end up in a dead key
state with `¨` waiting for the next character to be typed. Type
`backspace`. The `¨` should be removed, but it's not.
With this change, the `backspace` is interpreted instead of being
ignored.
Release Notes:
- Fixed backspace not working for dead keys (i.e. when typing accents or
umlauts)
---------
Co-authored-by: Antonio <antonio@zed.dev>
Co-authored-by: Conrad <conrad@zed.dev>
This is a rebase of @gabydds text_system updates. with some small
cleanups.
Currently cannot test this as build is not working in linux. Im just
putting it up here before I forget about it.
---------
Co-authored-by: gabydd <gabydinnerdavid@gmail.com>
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
Release Notes:
- N/A
Hello everyone,
glad to be contributing to this awesome project! This just fixes a
simple todo!(linux) in gpui.
I also considered setting the window title in the hello world example,
let me know if I should add it in this PR as well.
Best Regards,
Christian Bergschneider
Release Notes:
- Fixed a bug that caused Zed to render at 60fps even on ProMotion
displays.
- Fixed a bug that could saturate the main thread event loop in certain
circumstances.
---------
Co-authored-by: Thorsten <thorsten@zed.dev>
Co-authored-by: Nathan <nathan@zed.dev>
Co-authored-by: Max <max@zed.dev>
This PR adds the initial support for loading extensions in Zed.
### Extensions Directory
Extensions are loaded from the extensions directory.
The extensions directory has the following structure:
```
extensions/
installed/
extension-a/
grammars/
languages/
extension-b/
themes/
manifest.json
```
The `manifest.json` file is used internally by Zed to keep track of
which extensions are installed. This file should be maintained
automatically, and shouldn't require any direct interaction with it.
Extensions can provide Tree-sitter grammars, languages, and themes.
Release Notes:
- N/A
---------
Co-authored-by: Marshall <marshall@zed.dev>
This PR changes our approach to initializing the `SystemAppearance` so
that we can do it earlier in the startup process.
Previously we were using the appearance from the window, meaning that we
couldn't initialize the value until we first opened the window.
Now we read the `window_appearance` from the `AppContext`. On macOS this
is backed by the
[`effectiveAppearance`](https://developer.apple.com/documentation/appkit/nsapplication/2967171-effectiveappearance)
on the `NSApplication`.
We currently still watch for changes to the appearance at the window
level, as the only hook I could find in the documentation is
[`viewDidChangeEffectiveAppearance`](https://developer.apple.com/documentation/appkit/nsview/2977088-viewdidchangeeffectiveappearance),
which is at the `NSView` level.
In my testing this makes it so Zed appropriately chooses the correct
light/dark theme on startup.
Release Notes:
- N/A
Reverts zed-industries/zed#7481
This would regress performance because we'd be using the standard
library's hash maps everywhere, so reverting for now.
With upcoming release of 1.76 I did a check of current +beta (which
seems to already be at 1.77). These would cause CI pipeline failures
once 1.77 is out.
Release Notes:
- N/A
This takes down LLVM IR size of theme_selector from 316k to ~250k. Note
that I do not care about theme_selector in particular, though it acts as
a benchmark for smaller crates to me ("how much static overhead in
compile time does gpui have").
The title is a bit dramatic, so just to shed some light: by leaking a
type I mean forcing downstream crates to codegen it's methods/know about
it's drop code. Since SubscriberSet is no longer used directly in the
generic (==inlineable) methods, users no longer have to codegen `insert`
and co.
Release Notes:
- N/A
This was causing an issue where windows about 1/10 of the way across the
display would hang for a fully second after being deactivated.
Release Notes:
- N/A
Co-authored-by: max <max@zed.dev>
Co-authored-by: nathan <nathan@zed.dev>
Co-authored-by: antonio <antonio@zed.dev>
This fixes `cmd+k` in the terminal taking 1s to have an effect. It is
now immediate.
It also fixes#7270 by ensuring that we don't set a bad state when
matching keybindings.
It matches keybindings per context and if it finds a match on a lower
context it doesn't keep pending keystrokes. If it finds two matches on
the same context level, requiring more keystrokes, then it waits.
Release Notes:
- Fixed `cmd-k` in terminal taking 1s to have an effect. Also fixed
sporadic non-matching of keybindings if there are overlapping
keybindings.
([#7270](https://github.com/zed-industries/zed/issues/7270)).
---------
Co-authored-by: Conrad <conrad@zed.dev>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
It allows us to receive messages from the dispatcher,
which breaks us out of waiting and lets us execute
main thread runnables as a part of the main loop.
This re-introduces the changes of #7305 but this time we create a
display link using the `NSScreen` associated with the window. We're
hoping we'll get these frame requests more reliably, and this seems
supported by the fact that awakening my laptop restores the frame
requests.
Release Notes:
- See #7305.
Co-authored-by: Nathan <nathan@zed.dev>
This pull request decreases the size of each instance buffer and shares
instance buffers across windows.
Release Notes:
- Improved GPU memory usage.
---------
Co-authored-by: Nathan Sobo <nathan@zed.dev>
This is achieved by starting a `CADisplayLink` that will invoke the
`on_request_frame` callback at the refresh interval of the display.
We only actually draw frames when the window was dirty, or for 2 extra
seconds after the last input event to ensure ProMotion doesn't downclock
the refresh rate when the user is actively interacting with the window.
Release Notes:
- Improved performance when using a ProMotion display with fast key
repeat rates.
---------
Co-authored-by: Nathan Sobo <nathan@zed.dev>
This improves a performance problem we were observing when having
multiple windows updating at the same time, where each window would
invalidate the other window's layout cache.
Release Notes:
- Improved performance when having multiple Zed windows open.
Co-authored-by: Max Brunsfeld <max@zed.dev>
This fixes a panic happening when releasing an instance buffer.
Releasing the buffer happens on a different thread but the borrow
checker was not catching it because the metal buffer completion handler
API doesn't have a `Send` marker on it.
Release Notes:
- N/A
This commit goes back to using `wait_until_scheduled` as opposed to
`wait_until_completed`. What this means, however, is that another draw
could take place before the previous one finished. When that happens we
don't want to reuse the same instance buffer because the GPU is actively
reading from it, so we use a pool instead.
Release Notes:
- Fixed a bug that caused inconsistent frame rate when scrolling on
certain hardware.
---------
Co-authored-by: Antonio Scandurra <me@as-cii.com>
Co-authored-by: Antonio <antonio@zed.dev>
Release Notes:
- Fixed a bug that caused inconsistent frame rate when scrolling on
certain hardware.
Co-authored-by: Antonio Scandurra <me@as-cii.com>
Co-authored-by: Nathan Sobo <nathan@zed.dev>
- Send app version and release stage to collab on connect
- Read the new header on the server
Release Notes:
- Added the ability to collaborate with users on different releases of
Zed.
This PR sorts the dependency lists in our `Cargo.toml` files so that
they are in alphabetical order.
This should make them easier to visually scan when looking for a
dependency.
Apologies in advance for any merge conflicts 🙈
Release Notes:
- N/A
This PR fixes this error when compiling a release build:
<img width="504" alt="Screenshot 2024-01-30 at 2 30 38 PM"
src="https://github.com/zed-industries/zed/assets/1486634/96470735-2b9e-4945-b4c3-c86ef0168b8c">
`DebugBelow` only exists when compiling with `debug_assertions`, so we
only want to implement it using that same criterion.
Release Notes:
- N/A
This should prevent a class of bugs where one queries the wrong type of
global, which results in oddities at runtime.
Release Notes:
- N/A
---------
Co-authored-by: Marshall <marshall@zed.dev>
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
This PR is a follow-up to #7084, where I noted that I wasn't satisfied
with using `SharedUri` to represent both URIs and paths on the local
filesystem:
> I'm still not entirely happy with this naming, as the file paths that
we can store in here are not _really_ URIs, as they are lacking a
protocol.
>
> I want to explore changing `SharedUri` / `SharedUrl` back to alway
storing a URL and treat local filepaths differently, as it seems we're
conflating two different concerns under the same umbrella, at the
moment.
`SharedUri` has now been reverted to just containing a `SharedString`
with a URI.
`ImageSource` now has a new `File` variant that is used to load an image
from a `PathBuf`.
Release Notes:
- N/A
This PR renames `SharedUrl` to `SharedUri` to better reflect its intent.
I'm still not entirely happy with this naming, as the file paths that we
can store in here are not _really_ URIs, as they are lacking a protocol.
I want to explore changing `SharedUri` / `SharedUrl` back to alway
storing a URL and treat local filepaths differently, as it seems we're
conflating two different concerns under the same umbrella, at the
moment.
Release Notes:
- N/A
This PR implements support for loading and displaying images from a
local file using gpui's `img` element.
API Changes:
- Changed `SharedUrl` to `SharedUrl::File`, `SharedUrl::Network`
Usage:
```rust
// load from network
img(SharedUrl::network(...)) // previously img(SharedUrl(...)
// load from filesystem
img(SharedUrl::file(...))
```
This will be useful when implementing markdown image support, because we
need to be able to render images from the filesystem (relative/absolute
path), e.g. when implementing markdown preview #5064.
I also added an example `image` to the gpui crate, let me know if this
is useful. Showcase:
<img width="872" alt="image"
src="https://github.com/zed-industries/zed/assets/53836821/b4310a26-db81-44fa-9a7b-61e7d0ad4349">
**Note**: The example is fetching images from [Lorem
Picsum](https://picsum.photos) ([Github
Repo](https://github.com/DMarby/picsum-photos)), which is a free
resource for fetching images in a specific size. Please let me know if
you're okay with using this in the example.
The fonts we embed in Zed binary (Zed Sans & Zed Mono) weigh about 30Mb in total and we are cloning them several times during startup and loading of embedded assets (once explicitly in Zed and then under the hood in font-kit). Moreover, after loading we have at least 2 copies of each font in our program; one in .rdata and the other on the heap for use by font-kit.
This commit does away with that distinction (we're no longer allocating the font data) and slightly relaxes the interface of `TextSystem::add_fonts` by expecting one to pass `Cow<[u8]>` instead of `Arc<Vec<u8>>`. Additionally, `AssetSource::get` now returns `Cow<'static, [u8]>` instead of `Cow<'self, [u8]>`; all existing implementations conform with that change.
Note that this optimization takes effect only in Release builds, as the library we use for asset embedding - rust-embed - embeds the assets only in Release mode and in Dev builds it simply loads data from disk. Thus it returns `Cow<[u8]>` in it's interface. Therefore, we still copy that memory around in Dev builds, but that's not really an issue.
This patch makes no assumptions about the build profile we're running under, that's just an intrinsic property of rust-embed.
Tl;dr: this should shave off about 30Mb of memory usage and a fair chunk (~30ms) of startup time.
Release Notes:
- Improved startup time and memory usage.
Something is stomping over the timestamp of generated scene.h right
after the build script finishes:
`Dirty gpui v0.1.0 (/Users/someonetoignore/work/zed/zed/crates/gpui):
the file target/debug/build/gpui-ca04eedfe8d0e13c/out/scene.h has
changed (1705922004.637000680s, 1s after last build at
1705922003.507431315s)`
^ That's an output of `-v` flag added to either `cargo run` or `cargo
build`.
This comes up when you do `cargo build` followed by `cargo run` or
another `cargo build`; the artifact is not getting reused, even though
it should be possible?
Release Notes:
- N/A
Was moved by mistake in: ebbe52e6b0
This was throwing errors everywhere on Linux because anyhow is needed by
the code and is not macOS dependent.
Release Notes:
- N/A
Simplify Zed's collaboration system by:
- Only allowing member management on root channels.
- Disallowing moving sub-channels between different roots.
- Disallowing public channels nested under private channels.
This should make the mental model easier to understand, and makes it
clearer
who has what access. It is also significantly simpler to implement, and
so
hopefully more performant and less buggy.
Still TODO:
- [x] Update collab_ui to match.
- [x] Fix channel buffer tests.
Release Notes:
- Simplified channel membership management.
One of the complaints of users on our first Hack call was that the error
messages you got when channel joining failed were not great.
This aims to fix that specific case, and lay the groundwork for future
improvements.
It adds two new methods to anyhow::Error
* `.error_code()` which returns a value from zed.proto (or
ErrorCode::Internal if the error has no specific tag)
* `.error_tag("key")` which returns the value of the tag (or None).
To construct errors with these fields set, you can use a builder API
based on the ErrorCode type:
* `Err(ErrorCode::Forbidden.anyhow())`
* `Err(ErrorCode::Forbidden.message("cannot join channel").into())` - to
add any context you want in the logs
* `Err(ErrorCode::WrongReleaseChannel.tag("required", "stable").into())`
- to add structured metadata to help the client handle the error better.
Release Notes:
- Improved error messaging when channel joining fails.
Sometimes Cocoa calls app delegate methods (notably the display link)
while we're calling Cocoa methods. This causes a deadlock unless we
are careful to run cocao methods while we're not holding our internal
locks
Since our last measurements, startup time in Zed had regressed quite
significantly. This was due to several issues:
- We were loading IBMPlex, which we're not really using in the UI.
- Images were being parsed in the foreground, thus blocking the main
thread
- Language models (for semantic index and assistant) were being loaded
in the foreground, thus blocking the main thread
- Interaction with the keychain was blocking the main thread
In addition to these, with this pull request we will now deserialize the
items for a pane in parallel, as opposed to doing so sequentially.
All combined, when running the zed binary directly this brings startup
time from ~350ms to ~210ms on my machine.
Release Notes:
- Improved startup time.
We recently doubled the size of the `ELEMENT_ARENA` after someone ran
into a panic due to the arena running out of space.
This adds some logging so that we can hopefully develop a better
understanding of when the element area's allocation is elevated.
Release Notes:
- N/A
This fixes the performance problem we saw in
https://github.com/zed-industries/community/issues/2405.
In a trace we could see that if a font is missing we'd constantly look
it up and never cache that it's missing.
This changes that and does cache the font-is-missing result.
Drawback is that one would need to restart Zed after installing a
missing font that was configured in settings. That seems acceptable for
now, though.
Release Notes:
- Improved rendering performance when configured fonts are missing on
the system.
We recently doubled the size of the `ELEMENT_ARENA` after someone ran
into a panic due to the arena running out of space.
This adds some logging so that we can hopefully develop a better
understanding of when the element area's allocation is elevated.
Co-authored-by: Antonio <antonio@zed.dev>
This fixes the performance problem we saw in https://github.com/zed-industries/community/issues/2405.
In a trace we could see that if a font is missing we'd constantly look
it up and never cache that it's missing.
This changes that and does cache the font-is-missing result.
Drawback is that one would need to restart Zed after installing a
missing font that was configured in settings. That seems acceptable for
now, though.
Co-authored-by: Antonio <antonio@zed.dev>
This fixes a panic we just saw on nightly. It's the first time we
see this panic, so I think it's pretty safe to assume having twice as
much capacity will fix it.
This PR does some cleanup of the `gpui` docs, making sure we're linking
things appropriately and following good Rust documentation style.
Release Notes:
- N/A
This PR adds a barebones README to the `gpui` crate, just so folks have
somewhere to land on when we link them here from
[gpui.rs](https://www.gpui.rs/).
We can flesh this out as we go.
Release Notes:
- N/A
This isn't my favorite idea of a fix, but it does work for now, and it
seems likely the terminal will need to configure other aspects of action
dispatch in the future.
In the future we should explore making it possible to do this via the
keymap, either by making disabling bindings more robust; or by having a
way to indicate immediate mode per binding.
Release Notes:
- Fixed a bug where cmd-k in terminal took 1s
This isn't my favorite idea of a fix, but it does work for now, and it
seems likely the terminal will need to configure other aspects of action
dispatch in the future.
In the future we should explore making it possible to do this via the
keymap, either by making disabling bindings more robust; or by having a
way to indicate immediate mode per binding.
This optimizes rendering time by saving computation of the layer_id and
comparison when inserting it into the `BTreeMaps`.
Co-authored-by: Antonio <antonio@zed.dev>
I was unable to run the collab tests locally because I would run out of
file descriptors.
From some digging it turned out that tokio allocates a new file
descriptor to do work on the CurrentThread using KQUEUE.
We create a new tokio Runtime with each database connection, and these
database connections were being retained by the Client, which is
retained by the Context.
Cleaning up our leaked contexts (and an unrelated retain cycle in the
UserStore) fixes the problem (though does make me
wonder if a different approach might be preferrable).
Release Notes:
- N/A
I was unable to run the collab tests locally because I would run out of
file descriptors.
From some digging it turned out that tokio allocates a new file
descriptor to do work on the CurrentThread using KQUEUE.
We create a new tokio Runtime with each database connection, and these
database connections were being retained by the Client, which is
retained by the Context.
Cleaning up our leaked contexts fixes the problem (though does make me
wonder if a different approach might be preferrable).
- it seems like layer.drawable_size() is 0,0 in metal_renderer.rs:189
- we set this in two places:
- in response to a CALayerDelegate setFrameSize: event
- in response to a CALayerDelegate viewDidChangeBackingProperties:
event.
- it looks like if we don't set it in either of these cases we get a
different failure mode: the view is zoomed just wrong.
- That said, I can reproduce the screenshot if .scale_factor() returns
0.
- This might happen if [nativeWindow screen] is nil, which happens when
the window is off screen.
- possible that zed started with offscreen window?
- I would expect that viewDidChangeBackingProperties would fire when
that changed.
- potential fix: default to 2.0
Release Notes:
- Fixed Zed occasionally rendering blank on laungh
([#2422](https://github.com/zed-industries/community/issues/2422)).
Add support for mapping `jk` to escape in vim mode.
This changes the behaviour of the keymatches when there are pending
matches.
Before: Even if there was a pending match, any complete matches would be
triggered and the pending state lost.
After: If there is a pending match, any complete matches are delayed by
1s, or until more keys are typed.
Release Notes:
- Added support for mapping `jk` in vim mode
([#2378](https://github.com/zed-industries/community/issues/2378)),
([#176](https://github.com/zed-industries/community/issues/176))
