This PR builds off of an earlier version of
https://github.com/zed-industries/zed/pull/9595, rearranges some of the
logic, and removes an unused platform API.
Release Notes:
- N/A
---------
Co-authored-by: apricotbucket28 <agustin.nicolas.marcos@outlook.com>
This PR changes GPUI to open windows with a default size and location,
and to otherwise inherit from their spawning window.
Note: The linux build now crashes on startup.
Release Notes:
- N/A
---------
Co-authored-by: Nathan <nathan@zed.dev>
Co-authored-by: Ezekiel Warren <zaucy@users.noreply.github.com>
See https://zed.dev/channel/gpui-536
Fixes https://github.com/zed-industries/zed/issues/9010
Fixes https://github.com/zed-industries/zed/issues/8883
Fixes https://github.com/zed-industries/zed/issues/8640
Fixes https://github.com/zed-industries/zed/issues/8598
Fixes https://github.com/zed-industries/zed/issues/8579
Fixes https://github.com/zed-industries/zed/issues/8363
Fixes https://github.com/zed-industries/zed/issues/8207
### Problem
After transitioning Zed to GPUI 2, we started noticing that interacting
with the mouse on many UI elements would lead to a pretty annoying
flicker. The main issue with the old approach was that hover state was
calculated based on the previous frame. That is, when computing whether
a given element was hovered in the current frame, we would use
information about the same element in the previous frame.
However, inspecting the previous frame tells us very little about what
should be hovered in the current frame, as elements in the current frame
may have changed significantly.
### Solution
This pull request's main contribution is the introduction of a new
`after_layout` phase when redrawing the window. The key idea is that
we'll give every element a chance to register a hitbox (see
`ElementContext::insert_hitbox`) before painting anything. Then, during
the `paint` phase, elements can determine whether they're the topmost
and draw their hover state accordingly.
We are also removing the ability to give an arbitrary z-index to
elements. Instead, we will follow the much simpler painter's algorithm.
That is, an element that gets painted after will be drawn on top of an
element that got painted earlier. Elements can still escape their
current "stacking context" by using the new `ElementContext::defer_draw`
method (see `Overlay` for an example). Elements drawn using this method
will still be logically considered as being children of their original
parent (for keybinding, focus and cache invalidation purposes) but their
layout and paint passes will be deferred until the currently-drawn
element is done.
With these changes we also reworked geometry batching within the
`Scene`. The new approach uses an AABB tree to determine geometry
occlusion, which allows the GPU to render non-overlapping geometry in
parallel.
### Performance
Performance is slightly better than on `main` even though this new
approach is more correct and we're maintaining an extra data structure
(the AABB tree).
Release Notes:
- Fixed a bug that was causing popovers to flicker.
---------
Co-authored-by: Nathan Sobo <nathan@zed.dev>
Co-authored-by: Thorsten <thorsten@zed.dev>
Also adds a new command `cli: Register Zed Scheme` that will cause URLs
to be opened in the current zed version, and we call this implicitly if
you install the CLI
Also add some status reporting to install cli
Fixes: #8857
Release Notes:
- Added success/error reporting to `cli: Install Cli`
([#8857](https://github.com/zed-industries/zed/issues/8857)).
- Removed `zed-{preview,nightly,dev}:` url schemes (used by channel
links)
- Added `cli: Register Zed Scheme` to control which zed handles the
`zed://` scheme (defaults to the most recently installed, or
the version that you last used `cli: Install Cli` with)
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
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 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
