zed/crates/collab
Antonio Scandurra 4700d33728
Fix flickering (#9012)
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).


![before_after](https://github.com/zed-industries/zed/assets/482957/c8120b07-1dbd-4776-834a-d040e569a71e)

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>
2024-03-11 10:45:57 +01:00
..
k8s Remove console-subscriber (#8955) 2024-03-06 10:26:59 -07:00
migrations Denormalize buffer operations (#9026) 2024-03-07 11:35:47 -07:00
migrations.sqlite Denormalize buffer operations (#9026) 2024-03-07 11:35:47 -07:00
src Fix flickering (#9012) 2024-03-11 10:45:57 +01:00
.admins.default.json Make zed-local support opening 5 or 6 zed instances 2024-01-18 12:18:12 -08:00
.env.toml Upload crashes to collab directly (#8649) 2024-03-01 13:23:44 -07:00
admin_api.conf Run postgrest as part of foreman 2023-09-13 12:32:15 -07:00
basic.conf Rename zed-server to collab 2022-04-09 08:30:42 -06:00
Cargo.toml Migrate from scrypt to sha256. (#8969) 2024-03-06 20:51:43 -07:00
LICENSE-AGPL chore: Add crate licenses. (#4158) 2024-01-23 16:56:22 +01:00
README.md Deploy collab like nightly (#7174) 2024-02-01 11:54:49 -07:00

Zed Server

This crate is what we run at https://collab.zed.dev.

It contains our back-end logic for collaboration, to which we connect from the Zed client via a websocket after authenticating via https://zed.dev, which is a separate repo running on Vercel.

Local Development

Detailed instructions on getting started are here.

Deployment

We run two instances of collab:

Both of these run on the Kubernetes cluster hosted in Digital Ocean.

Deployment is triggered by pushing to the collab-staging (or collab-production) tag in Github. The best way to do this is:

  • ./script/deploy-collab staging
  • ./script/deploy-collab production

You can tell what is currently deployed with ./script/what-is-deployed.

Database Migrations

To create a new migration:

./script/sqlx migrate add <name>

Migrations are run automatically on service start, so run foreman start again. The service will crash if the migrations fail.

When you create a new migration, you also need to update the SQLite schema that is used for testing.