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>
Adding the typos crate to our CI will take some doing, as we have
several tests which rely on typos in various ways (e.g. checking state
as the user types), but I thought I'd take a first stab at fixing what
it finds.
Release Notes:
- N/A
This PR renames the `h_stack` and `v_stack` to `h_flex` and `v_flex`,
respectively.
We were previously using `h_stack` and `v_stack` to match SwiftUI, but
`h_flex` and `v_flex` fit better with the web/flexbox terminology that
the rest of GPUI uses.
Additionally, we were already calling the utility functions used to
implement `h_stack` and `v_stack` by the new names.
Release Notes:
- N/A
This PR deletes the old `ui` and `storybook` crates in favor of their
newer variants that we'll be landing to `main` in the near future.
### Motivation
These crates are based off the old version of GPUI 2 (the `gpui2`
crate).
At this point we have since transitioned to the new version of GPUI 2
(the `gpui3` crate, currently still on the `gpui2` branch).
Having both copies around is confusing, so the old ones are going the
way of the dinosaurs.
Release Notes:
- N/A
This PR mainlines the current state of new GPUI2-based UI from the
`gpui2-ui` branch.
Included in this is a performance improvement to make use of the
`TextLayoutCache` when calling `layout` for `Text` elements.
Release Notes:
- N/A
---------
Co-authored-by: Nate Butler <iamnbutler@gmail.com>
Co-authored-by: Antonio Scandurra <me@as-cii.com>
This PR fixes the kitchen sink story in the storybook.
Included are some additional changes that make it so the kitchen sink is
automatically populated by all of the defined stories.
Release Notes:
- N/A
This PR factors out the bulk of the boilerplate required to setup a
story in the storybook out into separate components.
The pattern we're using here is adapted from the "[associated
component](https://maxdeviant.com/posts/2021/react-associated-components/)"
pattern in React.
Release Notes:
- N/A
This PR updates the `storybook` with support for adding stories for
individual components.
### Motivation
Right now we just have one story in the storybook that renders an entire
`WorkspaceElement`.
While iterating on the various UI components, it will be helpful to be
able to create stories of those components just by themselves.
This is especially true for components that have a number of different
states, as we can render the components in all of the various states in
a single layout.
### Explanation
We achieve this by adding a simple CLI to the storybook.
The `storybook` binary now accepts an optional `[STORY]` parameter that
can be used to indicate which story should be loaded. If this parameter
is not provided, it will load the workspace story as it currently does.
Passing a story name will load the corresponding story, if it exists.
For example:
```
cargo run -- elements/avatar
```
<img width="723" alt="Screenshot 2023-09-21 at 10 29 52 PM"
src="https://github.com/zed-industries/zed/assets/1486634/5df489ed-8607-4024-9c19-c5f4541f97c9">
```
cargo run -- components/facepile
```
<img width="785" alt="Screenshot 2023-09-21 at 10 30 07 PM"
src="https://github.com/zed-industries/zed/assets/1486634/e04a4577-7403-405d-b23c-e765b7a06229">
Release Notes:
- N/A
Marshall Bowers
Kirill Bulatov
Bennet Bo Fenner
Mikayla
JuliaandNathan Sobo
Conrad Irwin
Piotr OsiewiczandKirill
Max BrunsfeldandMikayla
