Fixes a regression introduced in
https://github.com/zed-industries/zed/pull/34992
### Background
Paths are rendered first to an intermediate MSAA texture, and then
copied to the final drawable. Because paths can have transparency, it's
important that pixels are not copied repeatedly if paths have
overlapping bounding boxes. When N paths have the same draw order, we
infer that they must have disjoint bounding boxes, so that we can copy
them each individually (as opposed to copying a single rect that
contains them all). Previously, the bounding box that we were using to
copy paths was not accounting for the path's content mask (but it is
accounted for in the bounds tree that determines their draw order).
This cause bugs like this, where certain path pixels spuriously had
their opacity doubled:
https://github.com/user-attachments/assets/d792e60c-790b-49ad-b435-6695daba430f
This PR fixes that bug.
* [x] mac
* [x] linux
* [x] windows
Release Notes:
- Fixed a bug where a selection's opacity was computed incorrectly when
it overlapped with another editor's selections in a certain way.
This is another attempt to solve the same problem as
https://github.com/zed-industries/zed/pull/29718, while avoiding the
regression on Intel GPUs.
### Background
Currently, on main, all paths are first rendered to an intermediate
"atlas" texture, similar to what we use for rendering glyphs, but with
multi-sample antialiasing enabled. They are then drawn into our actual
frame buffer in a separate pass, via the "path sprite" shaders.
Notably, the intermediate texture acts as an "atlas" - the paths are
laid out in a non-overlapping way, so that each path could be copied to
an arbitrary position in the final scene. This non-overlapping approach
makes a lot sense for Glyphs (which are frequently re-used in multiple
places within a frame, and even across frames), but paths do not have
these properties.
* we clear the atlas every frame
* we rasterize each path separately. there is no deduping.
The problem with our current approach is that the path atlas textures
can end up using lots of VRAM if the scene contains many paths. This is
more of a problem in other apps that use GPUI than it is in Zed, but I
do think it's an issue for Zed as well. On Windows, I have hit some
crashes related to GPU memory.
In https://github.com/zed-industries/zed/pull/29718, @sunli829
simplified path rendering to just draw directly to the frame buffer, and
enabled msaa for the whole frame buffer. But apparently this doesn't
work well on Intel GPUs because MSAA is slow on those GPUs. So we
reverted that PR.
### Solution
With this PR, we rasterize paths to an intermediate texture with MSAA.
But rather than treating this intermediate texture like an *atlas*
(growing it in order to allocate non-overlapping rectangles for every
path), we simply use a single fixed-size, color texture that is the same
size as thew viewport. In this texture, we rasterize the paths in their
final screen position, allowing them to overlap. Then we simply blit
them from the resolved texture to the frame buffer.
### To do
* [x] Implement for Metal
* [x] Implement for Blade
* [x] Fix content masking for paths
* [x] Fix rendering of partially transparent paths
* [x] Verify that this performs well on Intel GPUs (help @notpeter 🙏 )
* [ ] Profile and optimize
Release Notes:
- N/A
---------
Co-authored-by: Junkui Zhang <364772080@qq.com>
Reverts zed-industries/zed#29718
We've noticed some issues with Zed on Intel-based Macs where typing has
become sluggish, and git bisect has seemed to point towards this PR.
Reverting for now, until we can understand why it is causing this issue.
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>
This PR contains a set of changes for improving FreeBSD support (#15309,
#29550) and is a kind of follow up to the PR #20480 which added an
initial support for FreeBSD.
A summary of changes is as follows:
- Add some more freebsd conditionals which seem missing in the previous
PR.
- Implement `anonymous_fd()` and `current_path()` functions for FreeBSD.
- Improve detection of FreeBSD in telemetry and GPU detection.
- Temporarily disable LiveKit/WebRTC support to make build succeed.
- Remove support for flatpak since it is Linux-only packaging format.
Adding `RUSTFLAGS="-C link-dead-code"` does not seem necessary anymore.
It builds fine without the flag.
Known issues:
- Integrated terminal is painfully laggy and virtually unusable in my
environment. This might be specific to my setup.
- I cannot input Japanese using IME. When I type characters, they appear
on the screen. But when I hit return key, they disappears. Seems the
same issue as #15409.
My environment is MATE desktop on X11 on FreeBSD 14.2 on Intel Core
i5-7260U integrated graphics.
P.S. For those who might be interested, a work-in-progress FreeBSD port
and binary packages are available at
https://github.com/tagattie/FreeBSD-Zed
Release Notes:
- N/A
---------
Co-authored-by: Peter Tripp <peter@zed.dev>
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
Closes#28533
Release Notes:
- Linux: Improved parsing of `ZED_DEVICE_ID` environment variable in an
attempt to fix some cases where it erroneously failed to parse. The
`ZED_DEVICE_ID` is now expected to always be a 4 digit hexadecimal
number (as it is in the output of `lcpci`) with an optional `0x` or `0X`
prefix.
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>
Workaround for users affected by #25899
Thanks to the work done by @kvark in
https://github.com/kvark/blade/pull/210, we have the ability to tell
Vulkan (through blade) a specific GPU to use.
This will hopefully allow some of the users affected by #25899 to use
Zed by allowing them to use a specific GPU, if the primary/default GPU
will not work
Release Notes:
- Added the ability to specify which GPU Zed uses on Linux by setting
the `ZED_DEVICE_ID` environment variable. You can obtain the device ID
of your GPU by running `lspci -nn | grep VGA` which will output each GPU
on one line like:
```
08:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA104
[GeForce RTX 3070] [10de:2484] (rev a1)
````
where the device ID here is `2484`. This value is in hexadecimal, so to
force Zed to use this specific GPU you would set the environment
variable like so:
```
ZED_DEVICE_ID=0x2484
```
Make sure to export the variable if you choose to define it globally in
a `.bashrc` or similar
There apparently is some amdgpu/radv bug that rendering with
multisample anti-aliasing (MSAA) results in a crash when the bounds
of a triangle list exceed 1024px, which in Zed happens with the default
buffer font size when you select a line with more than 144 characters.
This crash has been reported as #26143.
This commit introduces a workaround: you can set the
ZED_PATH_SAMPLE_COUNT=0
environment variable to disable MSAA and the error message we print
when a GPU crash is encountered with radv now suggests trying this
environment
variable as a workaround and links the respective issue.
Sidenote: MSAA was introduced in
f08b1d78ec
so you didn't run into this driver bug with versions < 0.173.8.
Release Notes:
- Added a workaround for an AMD Linux driver bug that causes Zed to
crash when selecting long lines.
Closes #ISSUE
[git: Use font size to determine pattern slash width
#26446](https://github.com/zed-industries/zed/pull/26446)
This PR only uses font size as the slant line width, and here it further
uses line height as the slant line interval control.
before
now
big line height
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Release Notes:
- Render unstaged hunks in the project diff editor with a slashed
background
---------
Co-authored-by: maxbrunsfeld <max@zed.dev>
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
Closes#20762
Release Notes:
- N/A
---
Enable MSAA for Anti-Aliasing to Path (`cx.paint_path`) for drawing a
better vector graphics.
```bash
cargo run -p gpui --example gradient --features macos-blade
cargo run -p gpui --example gradient
cargo run -p gpui --example painting --features macos-blade
cargo run -p gpui --example painting
```
**Before**
<img width="1089" alt="image"
src="https://github.com/user-attachments/assets/0ae7240f-4ba9-4ef5-896c-e436c1282770"
/>
**After**
<img width="944" alt="image"
src="https://github.com/user-attachments/assets/71a07ae8-be54-452c-aacc-b8cec1f810c0"
/>
## TODO
- [x] Support Metal and Blade.
- [x] Detect system support to set up sample count.
- [x] Fix extra lines between Path vertices wait #22808 to merge.
Ref https://github.com/kvark/blade/pull/213
Ask @kvark to review.
I am not sure if there is anything I missed. I modified it according to
the
[particle](https://github.com/kvark/blade/tree/main/examples/particle)
example of Blade project. But the difference is that after the first
MSAA render, I did not do it a second time, I tested it and found it was
not necessary.
TODO:
- [x] BackgroundOrientation
- [x] PatternDash
- [x] `pattern_horizontal_dash` & `pattern_vertical_dash`
- [x] Metal dash shader
- [x] Blade dash shader
- [x] Update ui::Divider to use new pattern
---
This PR introduces proper dashed dividers using the new `PatternDash`
background shader.
Before this we were using 128 elements to create a dashed divider, which
is both expensive, and would not scale beyond a certain size. This
allows us to simplify the divider element as well.
Changes:
- Adds `BackgroundOrientation` to `gpui::color::Background` to allow
specifying a direction for a pattern
- Adds the PatternDash pattern variant
- Updates `ui::Divider`'s dashed variants to be more efficient
Misc:
- Documents the `ui::Divider` component
- Treat `.metal` files as `C` in the Zed project until we get some metal
syntax highlighting.
Release Notes:
- N/A
TODO:
- [x] Add BackgroundTag::PatternSlash
- [x] Support metal slash pattern fills
- [x] Support blade slash pattern fills
---
Adds support for a new background type in gpui, `pattern_slash`.
Usage:
```rust
div().size(px(56.0)).bg(pattern_slash(gpui::red()))
```
This will create a 56px square with a red slash pattern fill.
You can run the pattern example with `cargo run -p gpui --example
pattern`:
---
After talking with @as-cii at length about how we want to support
patterns in gpui, we decided for now we'll simply add a new
BackgroundTag specific to this pattern.
It isn't the best long term plan however – we'll likely want to
introduce the concept of a `Fill` at some point so we can have
`Fill::Solid`, `Fill::Gradient(LinearGradient)`, etc in the future.
The pattern is designed to seamlessly tile vertically for elements of
the same height. For example, for use in editor line backgrounds:
---
Release Notes:
(do we do gpui release notes?)
- Adds support for slash pattern fills in `gpui`.
---------
Co-authored-by: Antonio Scandurra <me@as-cii.com>
Closes#17005
Release Notes:
- Improved GPU context management: share a single context with multiple
surfaces.
### High Level
Blade got a proper support for Surface objects in
https://github.com/kvark/blade/pull/203.
That was mainly motivated by Zed needing to draw multiple windows. With
the Surface API, Zed is now able to have the GPU context tied to the
"Platform" instead of "Window". Practically speaking, this means:
- architecture more sound
- faster to open/close windows
- less surprises, more robust
### Concerns
1. Zed has been using a temporary workaround for the platform bug on
some Intel+Nvidia machines that makes us unable to present -
https://github.com/kvark/blade/pull/144 . This workaround is no longer
available with the new architecture. I'm looking for ideas on how to
approach this better.
- we are now picking up the change in
https://github.com/kvark/blade/pull/210, which allows forcing a specific
Device ID. This should allow Zed users to work around the issue. We
could help them to automate it, too.
2. ~~Metal-rs dependency is switched to
https://github.com/kvark/metal-rs/tree/blade, since upstream isn't
responsive in merging changes that are required for Blade. Hopefully,
temporary.~~
- ~~we can also hack around it by just transmuting the texture
references, since we know those are unchanged in the branch. That would
allow Blade to use it's own version of Metal, temporarily, if switching
metal-rs in the workspace is a concern.~~
- merged my metal-rs changes and updated Zed to use the upstream github
reference
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
This PR adds a function, WindowContext::drop_image, to manually remove a
RenderImage from the sprite atlas. In addition, PlatformAtlas::remove
was added to support this behavior. Previously, there was no way to
request a RenderImage to be removed from the sprite atlas, and since
they are not removed automatically the sprite would remain in video
memory once added until the window was closed. This PR allows a
developer to request the image be dropped from memory manually, however
it does not add automatic removal.
Release Notes:
- N/A
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
This will allow us to compile debug builds of the remote-server for a
different architecture than the one we are developing on.
This also adds a CI step for building our remote server with minimal
dependencies.
Release Notes:
- N/A
Release Notes:
- N/A
---
Add this for let GPUI element to support fade in-out animation.
## Platform test
- [x] macOS
- [x] blade `cargo run -p gpui --example opacity --features macos-blade`
## Usage
```rs
div()
.opacity(0.5)
.bg(gpui::black())
.text_color(gpui::black())
.child("Hello world")
```
This will apply the `opacity` it self and all children to use `opacity`
value to render colors.
## Example
```
cargo run -p gpui --example opacity
cargo run -p gpui --example opacity --features macos-blade
```
<img width="612" alt="image"
src="https://github.com/user-attachments/assets/f1da87ed-31f5-4b55-a023-39e8ee1ba349">
* 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
Release Notes:
- Fixed a (potential) small error in erf estimation. Technically, the
error is negligible.
I am not sure where the current calculation for erf come from and if it
is intended or a simple mistake. However it looks slightly different
from the official calculation, notably
[this](https://en.wikipedia.org/wiki/Error_function#Approximation_with_elementary_functions)
from Wikipedia.
I will add a comment if it is intended.
Release Notes:
- linux: Added GPU information to `editor: Copy System Specs to
Clipboard`
- linux: Show a prominant warning before running under llvmpipe and
similar.
Piotr Osiewicz
localcc
Max Brunsfeld
Joseph T. Lyons
SunliandJason Lee
Hiroki TagatoandPeter Tripp
Kirill Bulatov
tidely
Ben Kunkle
Michael Sloan
Martin Fischer
0x2CA
Nate Butler
Dzmitry Malyshau
Marshall Bowers
ensi
apricotbucket28
Thorsten BallandBennet
Son
