* Linux Clippy lints fixed
* Zed local tasks are now simpler to rerun
* Zed's `release-fast` build profile keeps the debug info so it's
possible to properly debug things without altering the sources
Release Notes:
- N/A
I want to showcase Zed's performance via videos, and this seemed like a
good way to demonstrate it.
https://github.com/user-attachments/assets/f4a5fabc-efe7-4b48-9ba5-719882fdc856
Release Notes:
- On macOS, you can now set assign `performance.show_in_status_bar:
true` in your settings to show the time to the first window draw on
startup and then current FPS of the containing window's renderer.
---------
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Co-authored-by: David Soria Parra <167242713+dsp-ant@users.noreply.github.com>
Co-authored-by: Danny Hua <danny.hua@hey.com>
Release Notes:
- linux: Added GPU information to `editor: Copy System Specs to
Clipboard`
- linux: Show a prominant warning before running under llvmpipe and
similar.
On most platforms, things were working correctly, but had the wrong
type. On X11, there were some problems with window and display size
calculations.
Release Notes:
- Fixed issues with window positioning on X11
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Co-authored-by: Mikayla <mikayla@zed.dev>
Release Notes:
- N/A
## What
Addresses a long-standing issue of doing the blending operations in sRGB
space. Currently, the input HSL colors are provided in sRGB space and
converted to linear in the vertex shader. Conversion back to sRGB, which
is required on most platforms today, happens at the very end of the
pipeline when writing into sRGB render target.
Note-1: in the future we may consider doing HSL -> sRGB -> Linear
transform on CPU before feeding into shaders. However, I don't expect
any significant difference here given that we are likely bound by fill
rate and pixel shaders, anyway.
Note-2: the graphics stack is programmed to detect if the platform
supports presenting in linear color space and avoids converting to sRGB
at the end in this case. However, on my Z13 laptop this isn't supported
by the RADV driver.
Closes#7684Closes#11462
@jansol please confirm if you can!
## Comparison
Screenshot of the Glazier theme before the change:
Same theme after the change:
Release Notes:
- N/A
Picks up https://github.com/kvark/blade/pull/113 and a bunch of other
fixes.
Should prevent the exclusive full-screen on Vulkan - related to #9728
cc @kazatsuyu
Note: this PR doesn't enable transparency, this is left to follow-up
Release Notes:
- N/A
Picks up https://github.com/kvark/blade/pull/105,
https://github.com/kvark/blade/pull/97, and more
Switches the presentation to be non-blocking, which will improve the
latency slightly.
Allows to start playing with GLES backend, e.g.
```bash
cd crates/gpui
RUSTFLAGS="--cfg gles" CARGO_TARGET_DIR=./target-gl cargo run --example hello_world
```
It doesn't currently render properly due to an issue that needs
investigation, see
https://github.com/kvark/blade/pull/105#issuecomment-2041006542
But at least it's a start
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
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
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
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
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>
2024-02-16 13:39:40 -08:00
Renamed from crates/gpui/src/platform/linux/blade_renderer.rs (Browse further)
