Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix image_loader for animated image types #5688

Merged
merged 2 commits into from
Feb 18, 2025
Merged

Fix image_loader for animated image types #5688

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
b42a203
Fix image_loader for animated image types
BSteffaniak Feb 5, 2025
652d75d
Add todo comment
lucasmerlin Feb 18, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions crates/egui_extras/src/loaders/image_loader.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,5 +1,6 @@
use ahash::HashMap;
use egui::{
decode_animated_image_uri,
load::{BytesPoll, ImageLoadResult, ImageLoader, ImagePoll, LoadError, SizeHint},
mutex::Mutex,
ColorImage,
Expand Down Expand Up @@ -58,6 +59,11 @@ impl ImageLoader for ImageCrateLoader {
// 2. Mime from `BytesPoll::Ready`
// 3. image::guess_format (used internally by image::load_from_memory)

// TODO(lucasmerlin): Egui currently changes all URIs for webp and gif files to include
// the frame index (#0), which breaks if the animated image loader is disabled.
// We work around this by removing the frame index from the URI here
let uri = decode_animated_image_uri(uri).map_or(uri, |(uri, _frame_index)| uri);
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't like it because I feel like the image loader shouldn't need to know about animated images. The culprit is here, but fixing it there would be a much bigger change so I think this fix is fine fow now.

In theory this should break urls like http://example.com/image.png#123, where the loader now would try to load http://example.com/image.png, but I these urls are very rare so this should be fine.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Right, that's why I pointed out that we shouldn't even be treating the static webp images as animated (in is_animated_image_uri). Would you like me to take a look at fixing that?

Copy link
Contributor Author

@BSteffaniak BSteffaniak Feb 10, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

Oops, sorry, I didn't mean that I think this fix should be in is_animated_image_uri. I think it would be around are_animated_image_bytes

Copy link
Contributor Author

Choose a reason for hiding this comment

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

For fixing specifically webp, I would image something like this:

has_gif_magic_header(bytes) || (has_webp_header(bytes) && is_animated_webp_header(bytes))

I haven't looked into the gif spec to see if there is a similar header that we could look at for that.

lucasmerlin marked this conversation as resolved.
Show resolved Hide resolved

// (1)
if uri.starts_with("file://") && !is_supported_uri(uri) {
return Err(LoadError::NotSupported);
Expand Down
Loading