Need help implementing background image

[daladim]

Hello,

Following #1221, I've just started adding support for background images in Iced. After literally 3 lines of code (in iced_graphics), I had a working example !
But now I need your advice to turn this to a viable feature that I would then push into a merge request.

I'd like to add a Image variant into the Background enum. This variant could either be:

• Image(PathBuf), but that would mean the image has to be re-loaded from its Path and re-parsed from disk every time the window is drawn, so that's not a good idea
• Image(image::Handle) (or maybe Image(Arc<Handle>) if that's necessary), but image::Handle is defined in iced_native, whereas Background comes from iced_core.

So, I have two options:

• iced_native is obviously not suitable to become a dependency for iced_core
• move image::Handle to iced_core (possibly gated by a Cargo feature). The Handle code is rather simple, but still, it looks it requires some other dependencies from iced_native (e.g. the hasher), and I'm not sure this move will be very easy.
• do the opposite: move Background to iced_native, so that it can use Handles. But iced_style currently uses many Background::Color(...) variants, and we probably don't want it to depend on iced_native.
  So I guess I should rename the current core::Background as core::SolidBackground, and build a more complex iced_native::Background (that could be either Solid(SolidBackground) or Image(Handle), and maybe later Gardient(...))? Do you agree? Or is there a more sensible approach?

In case you have any idea, I'd be happy to hear it, so that I can implement backgound images quickly. Otherwise, I'll have to go by trial and error, and end up with a merge request that may not suit you...

Thanks for your advice!

[hecrj]

I think the best approach is to move image::Handle to iced_core.

However, as I mentioned in #674 (comment), the current implementations of Image and Svg have many shortcomings. We should tackle those first, as we may need to heavily rethink the way Handle works!

[daladim]

Thanks for your reply

I think the best approach is to move image::Handle to iced_core.

That's what I was considering as well.

We should tackle those first

I've just had a quick look, but I'm not sure I'm knowlegeable enough with iced (nor with images in general) to be really helpful. Still, I'll try to have a more thorough look later today.

I also have one more question for you, that I was wondering when reading the image::Handle implementation.
If I create a Handle using Handle::from_path(), will this image be loaded from the file everytime it is drawn (that's what is suggested by the fact that the handle only stores the path, rather than the decoded bytes), or is it cached somewhere (by a lower code layer? By the image crate itself?)
In other words, is is sensible performance-wise to create a handle to a large image using Handle::from_path(), or should I decode it once, then create a Handle::from_pixels(), to save IO/parsing/decoding time every time my window is refreshed?

Thanks

[daladim]

I have created a pull request (#1252)...which only focuses on the support for backgound images, not the other image-related issues :-/