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>
Gpui's build.rs will embed a manifest file into the Windows binary, but
sometimes we want to customize it, so I added a feature called
`no-windows-manifest` to disable this behavior.
Release Notes:
- N/A
Closes #ISSUE
Release Notes:
- Fixed a crash when screensharing on MacOS
Co-authored-by: Conrad <conrad@zed.dev>
Co-authored-by: Anthony Eid <hello@anthonyeid.me>
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 PR prevents situations like
https://github.com/zed-industries/zed/pull/23850, which caused our linux
nightly build to fail to open at all.
This PR also sorts the GPUI build and dev dependencies out from the sea
of platform specific dependencies.
Release Notes:
- N/A
Similar to #20826 but keeps the Swift implementation. There were quite a
few changes in the `call` crate, and so that code now has two variants.
Closes#13714
Release Notes:
- Added preliminary Linux support for voice chat and viewing
screenshares.
---------
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Co-authored-by: Mikayla <mikayla@zed.dev>
Issues found:
* audio does not work well with various set-ups using USB
* switching audio during initial join may leave the client with no audio
at all
* audio streaming is done on the main thread, beachballing certain
set-ups
* worse screenshare quality (seems that there's no dynamic scaling
anymore, compared to the Swift SDK)
This reverts commit 1235d0808e.
Release Notes:
- N/A
See https://github.com/livekit/rust-sdks/pull/355
Todo:
* [x] make `call` / `live_kit_client` crates use the livekit rust sdk
* [x] create a fake version of livekit rust API for integration tests
* [x] capture local audio
* [x] play remote audio
* [x] capture local video tracks
* [x] play remote video tracks
* [x] tests passing
* bugs
* [x] deafening does not work
(https://github.com/livekit/rust-sdks/issues/359)
* [x] mute and speaking status are not replicated properly:
(https://github.com/livekit/rust-sdks/issues/358)
* [x] **linux** - crash due to symbol conflict between WebRTC's
BoringSSL and libcurl's openssl
(https://github.com/livekit/rust-sdks/issues/89)
* [x] **linux** - libwebrtc-sys adds undesired dependencies on `libGL`
and `libXext`
* [x] **windows** - linker error, maybe related to the C++ stdlib
(https://github.com/livekit/rust-sdks/issues/364)
```
libwebrtc_sys-54978c6ad5066a35.rlib(video_frame.obj) : error LNK2038:
mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't
match value 'MD_DynamicRelease' in
libtree_sitter_yaml-df6b0adf8f009e8f.rlib(2e40c9e35e9506f4-scanner.o)
```
* [x] audio problems
Release Notes:
- Switch from Swift to Rust LiveKit SDK 🦀
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
Co-authored-by: Conrad Irwin <conrad@zed.dev>
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Co-authored-by: Michael Sloan <michael@zed.dev>
The biggest hurdle turned out to be use of `Arc<Language>` in maps, as
`clippy::mutable_key_type` started triggering on it (due to - I suppose
- internal mutability on `HighlightMap`?). I switched over to using
`LanguageId` as the key type in some of the callsites, as that's what
`Language` uses anyways for it's hash/eq, though I've still had to
suppress the lint outside of language crate.
/cc @maxdeviant , le clippy guru.
Release Notes:
- N/A
- Modify `build.rs` to use environment variables instead of `cfg`
directive to make cross-compilation to Windows possible
- Make `embed-resource` a global build-dependency for cross-compilation
Release Notes:
- N/A
One contributor to some beach-balls was that the main thread was calling
block_with_timeout, but the timeout never fired.
Release Notes:
- Reduced main thread hangs under very high system load
This is a follow up of #10810 , `embed-resource` crate uses a different
method to link the manifest file, so this makes moving manifest file to
`gpui` possible.
Now, examples can run as expected:
TODO:
- [ ] check if it builds with gnu toolchain
Release Notes:
- N/A
Updated version of #9741 with fixes for the problems raised in #9774. I
only verified that the images no longer look blueish on Linux, because I
don't have a Mac.
cc @osiewicz
Release Notes:
- N/A
---------
Signed-off-by: Niklas Wimmer <mail@nwimmer.me>
This removes bindgen and cbindgen from the dependency graph on non-macos
systems, improving compile times on those systems.
Signed-off-by: Niklas Wimmer <mail@nwimmer.me>
This PR makes Clippy deny all warnings across the workspace.
We now enumerate all of the rules that have violations and temporarily
allow them, with the goal being to drive the list down over time.
On Windows we don't yet use `--deny warnings`, as the Windows build
still has some warnings.
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>
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>
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
