Release Notes:
- Fixed a bug that caused inconsistent frame rate when scrolling on
certain hardware.
Co-authored-by: Antonio Scandurra <me@as-cii.com>
Co-authored-by: Nathan Sobo <nathan@zed.dev>
The fonts we embed in Zed binary (Zed Sans & Zed Mono) weigh about 30Mb in total and we are cloning them several times during startup and loading of embedded assets (once explicitly in Zed and then under the hood in font-kit). Moreover, after loading we have at least 2 copies of each font in our program; one in .rdata and the other on the heap for use by font-kit.
This commit does away with that distinction (we're no longer allocating the font data) and slightly relaxes the interface of `TextSystem::add_fonts` by expecting one to pass `Cow<[u8]>` instead of `Arc<Vec<u8>>`. Additionally, `AssetSource::get` now returns `Cow<'static, [u8]>` instead of `Cow<'self, [u8]>`; all existing implementations conform with that change.
Note that this optimization takes effect only in Release builds, as the library we use for asset embedding - rust-embed - embeds the assets only in Release mode and in Dev builds it simply loads data from disk. Thus it returns `Cow<[u8]>` in it's interface. Therefore, we still copy that memory around in Dev builds, but that's not really an issue.
This patch makes no assumptions about the build profile we're running under, that's just an intrinsic property of rust-embed.
Tl;dr: this should shave off about 30Mb of memory usage and a fair chunk (~30ms) of startup time.
Release Notes:
- Improved startup time and memory usage.
Sometimes Cocoa calls app delegate methods (notably the display link)
while we're calling Cocoa methods. This causes a deadlock unless we
are careful to run cocao methods while we're not holding our internal
locks
- it seems like layer.drawable_size() is 0,0 in metal_renderer.rs:189
- we set this in two places:
- in response to a CALayerDelegate setFrameSize: event
- in response to a CALayerDelegate viewDidChangeBackingProperties:
event.
- it looks like if we don't set it in either of these cases we get a
different failure mode: the view is zoomed just wrong.
- That said, I can reproduce the screenshot if .scale_factor() returns
0.
- This might happen if [nativeWindow screen] is nil, which happens when
the window is off screen.
- possible that zed started with offscreen window?
- I would expect that viewDidChangeBackingProperties would fire when
that changed.
- potential fix: default to 2.0
Release Notes:
- Fixed Zed occasionally rendering blank on laungh
([#2422](https://github.com/zed-industries/community/issues/2422)).
Before this change if you had a matching binding and a pending key,
the matching binding happened unconditionally.
Now we will wait a second before triggering that binding to give you
time to complete the action.
CGDisplayBounds returns data in "global display coordinates" (which are
the same as Zed's coordinates), different from the NS APIs which use
"screen coordinates" (which have the Y axis inverted)
Also remove some transmutes while we're at it
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
When the `List` element's state is `ListState::reset()`, it eagerly
trashes it's cached element heights in anticipation of a prompt render.
But, due to the recent `display_layer` changes, that re-render is not
always forthcoming. This is a problem for `ListState::scroll()`, which
depends on these cached elements to correctly calculate the new logical
scroll offset.
Solutions we attempted:
- Cache the element heights and continue the scroll calculation
- This was conceptually incorrect, reset should only be called when the
underlying data has been changed, making any calculation with the old
results meaningless.
- Lazily re-compute the element heights in scroll
- Beyond being a non-trivial refactor, this would probably also cause us
to double-render the list in a single frame, which is bad.
- Cache the scroll offset and only calculate it in paint
- This solution felt awkward to implement and meant we can't supply
synchronous list scroll events.
- Delay resetting until paint
- This means that all of the other APIs that `ListState` supplies would
give temporarily incorrect results, worsening the problem
Given these issues, we settled on the solution with the least
compromises: drop scroll events if the state has been `reset()` between
`paint()` and `scroll()`. This shifts the responsibility for the problem
out of the List element and into consumers of `List`, if you want
perfectly smooth scrolling then you need to use `reset()` judiciously
and prefer `splice()`.
That said, I tested this by aggressively scrolling the Collab panel, and
it seems to work as well as it did before.
This PR also includes some initial testing infrastructure for working
with input from the platform and rendered elements.
Release Notes:
- N/A
Previously, we were using `size_of` but passing the wrong type in
(MonochromeSprite instead of PathSprite). This caused us to read outside
of the `sprites` smallvec and triggered the segfault.
We're occasionally seeing a crash in MetalRenderer::draw.
Looking at the backtrace, it seems almost certainly to be happening in
the call to `ptr::copy_nonoverlapping` on line 604 (see `#Don't Panic!`
channel notes)
As we already have added bounds checking to the destination, it seems
most
likely (however improbable) that somehow we're getting an invalid Ptr
and
length from the SmallVec.
To try and make progress on this, let's try a Vec for a bit lest there
is a subtle issue in SmallVec (though I couldn't spot one).
Release Notes:
- (maybe) Fixes SEGFAULT in MetalRenderer::draw
Dzmitry Malyshau
Piotr OsiewiczandNiklas
Mikayla Maki
Conrad Irwin
Hans
Joseph T. Lyons
Kirill BulatovandPiotr