Skip to content

Cache raster uploads by physical draw size#318

Open
anthony-firn wants to merge 1 commit intopop-os:masterfrom
anthony-firn:anthony/raster-cache-physical-size
Open

Cache raster uploads by physical draw size#318
anthony-firn wants to merge 1 commit intopop-os:masterfrom
anthony-firn:anthony/raster-cache-physical-size

Conversation

@anthony-firn
Copy link
Copy Markdown

Summary

Follow-up to pop-os/libcosmic#1218.

That PR was correctly called out as the wrong layer. This moves the raster fix into the iced renderer, as requested in the review feedback there.

The change keeps decoded raster images in the renderer cache and keys atlas uploads by the physical draw size. Small surfaces can then reuse a downsampled upload that matches the actual target size instead of always sampling from the original source image.

Why

Third-party app icons in small COSMIC surfaces, especially the dock, can look rough when the renderer only reuses a single upload at the source image size.

Caching raster uploads by physical size lets the renderer prefilter the image once with Lanczos3 and then reuse that result across frames.

What changed

  • keep decoded raster images available in the wgpu raster cache
  • cache wgpu atlas uploads by (image id, physical width, physical height)
  • apply the same size-aware raster caching in tiny-skia
  • leave the SVG path unchanged

Validation

  • cargo check -p iced_wgpu -p iced_tiny_skia
  • live COSMIC dock validation against the applet-pinned iced snapshot using the same renderer-side size-aware cache approach

The current stock applet workspace still pins an older iced snapshot, so the live system verification was done against the equivalent renderer patch on that pinned tree before forward-porting it here.

Copy link
Copy Markdown

@wash2 wash2 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The image crate is optional and dependent on the image feature, so with this change, it should no longer be optional.

After fixing some build issues, I do see some improvement in the shimmering of images with the tiny-skia renderer, but wgpu rendering doesn't seem to shimmer even without this change. Is there a small example I could use to recreate shimmering with wgpu enabled?

Comment thread tiny_skia/src/raster.rs
image,
upload_size.width,
upload_size.height,
image_rs::imageops::FilterType::Lanczos3,
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't really have access to the requested FilterType for the image here. Do you think we could cache the result of a draw call from tiny-skia instead of caching a resized image at the allocation step? This is a pretty expensive filter, and some images being drawn may be better using a different method.

Comment thread wgpu/src/image/raster.rs
}

Some(
graphics::image::imageops::resize(
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this would effectively resize images using the CPU instead of the GPU, which is not ideal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants