Previously, we were using a normalized 8-bit unsigned integer which forced us
to represent each increment of the winding number as a fraction of the max
value (1 / 255) which we would then add up using additive alpha blending.
This had three major drawbacks:
- The max winding number could not be greater than 255.
- Adding up (1 / 255) several times could result in a loss of precision.
- Due to also computing anti-aliasing as a fractional winding number, we had to
reduce the max winding number to 32. This was still not good enough because
we would multiply a fractional value with `1 / 32`, thus introducing more and
more loss of precision.
This commit changes the texture type to an `f16` which doesn't require the
division by 255 and enables greater precision in the computation of the
anti-aliased parts of a curve. Note how this also removes the limitation of 255
windings at most per curve. The tradeoff is paying twice as much memory for
storing the texture, but that seems totally valid to achieve rendering accuracy.
Note that this kind of texture should be compatible with WebGL2 once we start
working on a web version of Zed.
Here I'm exploring a new approach to the project-wide diagnostics view that can exactly mirror the contents of cargo check. The `FragmentList` composes an arbitrary list of fragments from other buffers and presents them as if they were a single buffer.
This was causing us to get slower over time as we stacked up hundreds of thousands of pending edits whenever soft wrap was disabled.
Co-Authored-By: Antonio Scandurra <me@as-cii.com>
We perform an async fetch of client_b's user data on worktree_a, which ends up holding a handle that prevents worktree_a from being released later in the test. By waiting for this fetch to finish before proceeding, we can be sure worktree_a actually gets released.
A more comprehensive fix would be some way to ensure we actually perform a release if an entity is fully dropped outside of an update cycle, but this fixes the issue for now.
Co-Authored-By: Max Brunsfeld <max@zed.dev>
This will make it possible for us to render their avatars. Previously we only had the user ids. During rendering, everything needs to be available synchronously. So now, whenever collaborators are added, we perform the async I/O to fetch their user data prior to adding them to the worktree.
Again, this is about reserving the concept of a "collaborator" for actual collaborators on a worktree.
Co-Authored-By: Antonio Scandurra <me@as-cii.com>
This will allow us to use the word "collaborator" to describe users that are actively collaborating on a worktree.
Co-Authored-By: Antonio Scandurra <me@as-cii.com>
This is similar to the active entry, but it can remain assigned even if there is no active entry and we can potentially manipulate it in other scenarios such as interaction with the project browser. This prepares the ground to show the collaborators for the active worktree.
