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.

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

Bundle images #580

Closed
fenhl opened this issue Oct 26, 2020 · 3 comments · Fixed by #1453
Closed

Bundle images #580

fenhl opened this issue Oct 26, 2020 · 3 comments · Fixed by #1453
Labels
image performance question Further information is requested rendering

Comments

@fenhl
Copy link
Contributor

fenhl commented Oct 26, 2020

Is there a way to bundle images into the binary at compile time, rather than loading them from the file system at runtime (which means the app can't be a standalone .exe)?

@fenhl
Copy link
Contributor Author

fenhl commented Oct 26, 2020

I managed to find a workaround using iced::image::Handle::from_memory and std::include_bytes, but that involves cloning the images.

@hecrj hecrj added the question Further information is requested label Oct 28, 2020
@twitchyliquid64
Copy link

Seems related to #549 & #570. I agree we need a better way to load images into memory, and pass that through to the backend efficiently.

As for the specific problem of bundling images, I think include_bytes or writing into an ELF section in the binary is the way to go - I can't think of anything iced-specific here.

@twitchyliquid64
Copy link

Btw, you can 'bundle' images into the binary using the lazy_static macro/crate combined with the include_bytes builtin macro. The 'bundling' looks like this:

    pub static ref SOIC8: image::Handle =
        image::Handle::from_memory(include_bytes!("../../res/package/SOIC-8.png").to_vec());

From there, you can clone it + instantiate a new image:

Image::new(SOIC8.clone())

Note that this approach does an allocation + bytes copy as part of the render path, which isn't ideal. In practice this is fast enough for icon-sized images in release mode.

ids1024 added a commit to ids1024/iced that referenced this issue Oct 3, 2022
This should resolve iced-rs#580 by
providing a way to use an image included with `include_bytes!` without
needing to copy it to a vec `Vec` to create an image handle.

It would be nice if these methods could also be `const`, but that isn't
possible due to the hashing being done.

This is technically a breaking change since `Handle::data()` is public.
But if that is used, it's most likely in used somewhere that only relies
on the type derefing to `&[u8]`.
ids1024 added a commit to ids1024/iced that referenced this issue Oct 3, 2022
This should resolve iced-rs#580 by
providing a way to use an image included with `include_bytes!` without
needing to copy it to a `Vec` to create an image handle.

It would be nice if these methods could also be `const`, but that isn't
possible due to the hashing being done.

This is technically a breaking change since `Handle::data()` is public.
But if that is used, it's most likely in used somewhere that only relies
on the type derefing to `&[u8]`.
ids1024 added a commit to ids1024/iced that referenced this issue Oct 3, 2022
This should resolve iced-rs#580 by
providing a way to use an image included with `include_bytes!` without
needing to copy it to a `Vec` to create an image handle.

It would be nice if these methods could also be `const`, but that isn't
possible due to the hashing being done.

This is technically a breaking change since `Handle::data()` is public.
But if that is used, it's most likely in used somewhere that only relies
on the type derefing to `&[u8]`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
image performance question Further information is requested rendering
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants