Skip to content

Revert "Clean up image resources for the current window (#45969)" (#46779) (cherry-pick to preview)#46781

Merged
zed-zippy[bot] merged 1 commit intov0.219.xfrom
cherry-pick-v0.219.x-c35bbaad
Jan 14, 2026
Merged

Revert "Clean up image resources for the current window (#45969)" (#46779) (cherry-pick to preview)#46781
zed-zippy[bot] merged 1 commit intov0.219.xfrom
cherry-pick-v0.219.x-c35bbaad

Conversation

@zed-zippy
Copy link
Contributor

@zed-zippy zed-zippy bot commented Jan 14, 2026

Cherry-pick of #46779 to preview


This reverts commit 94faaeb.

The logic changed in the original
PR
is either
misplaced or lacks a counterpart that reacts on gpui::Image drop one
way or another.

The change was dropping the texture out of the global rendering atlas
when an image preview tab was disposed of, while in reality, another
instance (agent panel or another image preview tab) could require the
very same atlas entry to be rendered meanwhile.

Currently, only RetainAllImageCache in Zed does any kind of image
cleanup, and any other image usages will leak memory.
What makes it harder is that the atlas entry needs to live as long as a
particular Arc<Image> lives, and some public gpui API expects this
type to stay:

pub fn use_render_image(
self: Arc<Self>,
window: &mut Window,
cx: &mut App,
) -> Option<Arc<RenderImage>> {
ImageSource::Image(self)
.use_data(None, window, cx)
.and_then(|result| result.ok())
}
/// Use the GPUI `get_asset` API to make this image renderable
pub fn get_render_image(
self: Arc<Self>,
window: &mut Window,
cx: &mut App,
) -> Option<Arc<RenderImage>> {

For image viewer in particular, we need to consider why
RetainAllImageCache is not used there; for the global, normal fix, we
need to consider ways to have cx and window and a way to react on
Image drop.
As an option, we could break the gpui API (as it happens
periodically

already) and use Entity<Image> instead of Arc, then react with
cx.on_release_in for each such image.

Closes #46755
Closes #46435

Release Notes:

  • Fixed panics on concurrent image handling

…6779)

This reverts commit 94faaeb.

The logic changed in the [original
PR](#45969) is either
misplaced or lacks a counterpart that reacts on `gpui::Image` drop one
way or another.

The change was dropping the texture out of the global rendering atlas
when an image preview tab was disposed of, while in reality, another
instance (agent panel or another image preview tab) could require the
very same atlas entry to be rendered meanwhile.

Currently, only `RetainAllImageCache` in Zed does any kind of image
cleanup, and any other image usages will leak memory.
What makes it harder is that the atlas entry needs to live as long as a
particular `Arc<Image>` lives, and some public `gpui` API expects this
type to stay:

https://github.com/zed-industries/zed/blob/e747cfc955e8cfd9327d8d6b8d617cf1d3a6bcaa/crates/gpui/src/platform.rs#L1851-L1866

For image viewer in particular, we need to consider why
`RetainAllImageCache` is not used there; for the global, normal fix, we
need to consider ways to have `cx` and `window` and a way to react on
`Image` drop.
As an option, we could break the `gpui` API (as it [happens
periodically](#46183)
already) and use `Entity<Image>` instead of `Arc`, then react with
`cx.on_release_in` for each such image.

Closes #46755
Closes #46435

Release Notes:

- Fixed panics on concurrent image handling
@cla-bot cla-bot bot added the cla-signed The user has signed the Contributor License Agreement label Jan 14, 2026
@zed-zippy zed-zippy bot merged commit 0727934 into v0.219.x Jan 14, 2026
24 checks passed
@zed-zippy zed-zippy bot deleted the cherry-pick-v0.219.x-c35bbaad branch January 14, 2026 10:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cla-signed The user has signed the Contributor License Agreement

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant