Associates every window with its own refresh event. Removes the use of
X11 present.
Alternative to #8592.
Instead of doing the rendering on idle and then involving a hack for
polling X11 events, this PR just tries to do the rendering inside the
main loop. This guarantees that we continue to poll for events after the
draw, and not get screwed by the driver talking to X11 via the same file
descriptor.
Release Notes:
- N/A
This practice makes it difficult to locate todo!s in my code when I'm
working. Let's take out the bang if we want to keep doing this.
Release Notes:
- N/A
This reverts commit 0cebf68306.
Although this thing is very cool, it is a top source of crashes.
Example crash:
```
Segmentation fault: 11 on thread 26
objc_retain +16
invocation function for block in Overlay::onCommandBufferCommit(id<MTLCommandBuffer>) +60
MTLDispatchListApply +52
```
Release Notes:
- Removed "Toggle Graphics Profiler" as it crashes too much.
This PR unifies the event loop code for Wayland and X11. On Wayland,
blocking dispatch is now used. On X11, the invisible window is no longer
needed.
Release Notes:
- N/A
---------
Co-authored-by: Dzmitry Malyshau <kvark@fastmail.com>
Co-authored-by: Tadeo Kondrak <me@tadeo.ca>
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
Co-authored-by: julia <julia@zed.dev>
This uses bounds checking alone to determine hover state to avoid
flicker. It's a short-term solution because the rendering is incorrect.
We think this is better than flickering though and buys us some time as
we work on a more robust solution overall.
Release Notes:
- Fixed flickering when hovering.
---------
Co-authored-by: Nathan <nathan@zed.dev>
If the list is large (size > overdraw + available height) the
`all_rendered` check was preventing the list from returning an inferred
size. Theoretically we can now report heights which are actually too
small (because not all items were affected during layout), this can be
manually adjusted using the overdraw parameter. In this case its fine
because the picker is inside a max_height which should never be more
then the overdraw we specify (1000 px), and the list will shrink down
either way when the request_measured_layout callback is called again.
Release Notes:
- Fixed flashing of recent projects list when there were a lot of
projects in the list
([#8364](https://github.com/zed-industries/zed/issues/8364#issuecomment-1962849393)).
This is a follow up to #7945. The current behaviour reads the locale and
infers from that which type of time format should be used (12 hour/24
hour).
However, in macOS you can override this behaviour, e.g. you can use
en_US locale but still use the 24 hour clock format (Can be customized
under Settings > General > Date & Format > 24-hour time). You can even
customize the date format.
This PR uses the macOS specific `CFDateFormatter` API, which outputs
time format strings, that respect those settings.
Partially fixes#7956 (as its not implemented for linux)
Release Notes:
- Added localization support for all macOS specific date and time
configurations in chat
With this change, interaction with Zed is actually real-time and usable
🚀🎉
The gist of it is - trying to process all of the input events before
rendering anything.
Release Notes:
- N/A
**Note**: this can be further improved in a follow-up.
Currently, once the input and runnables are processed, we'd try to draw
+ render a frame.
Presentation starts with acquiring a new frame. We currently have FIFO
presentation method, so acquiring a frame is blocking on that swapchain
image to become available. As the result, presentation takes around 16
ms, most of which is just busy wait.
Ideally, we'd be able to process more input in this time frame, instead.
**Note2**: it's a bit laggy in Debug for me, but that's just because of
the extra-long `draw` times, which is unrelated to rendering (or
platform support, for the matter). I'm curious how come on MacOS the
`draw()` times in Debug are more modest.
[Profiling](https://crates.io/crates/profiling) crate allows easy
integration with various profiler tools. The best thing is - annotations
compile to nothing unless you request a specific feature.
For example, I used this command to enable Tracy support:
```bash
cargo run --features profiling/profile-with-tracy
```
At the same time I had Tracy tool open and waiting for connection. It
gathered nice stats from the run:
Release Notes:
- N/A
Fix an issue where the `ime_key` is sometimes an empty string, and
pressing a keystroke replaces the selected text.
E.g. select some text, press `Escape`: selected text is deleted.
Release Notes:
- Added `workspace::SendKeystrokes` to enable mapping from one key to a
sequence of others
([#7033](https://github.com/zed-industries/zed/issues/7033)).
Improves #7033. Big thank you to @ConradIrwin who did most of the heavy
lifting on this one.
This PR allows the user to send multiple keystrokes via custom
keybinding. For example, the following keybinding would go down four
lines and then right four characters.
```json
[
{
"context": "Editor && VimControl && !VimWaiting && !menu",
"bindings": {
"g z": [
"workspace::SendKeystrokes",
"j j j j l l l l"
],
}
}
]
```
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
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
