Stop hard-coding paths to images

[fschutt]

This is a fairly annoying issue: Currently the only way to add images is by using the limn::widgets::image::Image. This is hard-coded to use images from the ./assets/images/[myimage.png] if you pass in Image::new("myimage.png"). The reason it is bad to hard-code strings like this is because it is relative to the working directory from which the application was executed. It is very likely that the path ./assets/ will not be found, just because the working directory wasn't set correctly.

Another optimization is to use sprites (with offsets into the image) instead of using seperate images for each icon. So my proposal would be:

• Images should be forced to have an identifier, so that they can be looked up in a HashMap. In contrast to fonts, images do not need to be re-rendered.
• Using sprites can elimitate texture switches. This is important if you have tons of icons on the screen.
• Just let the user supply the image how he wants, as a decoded byte array (like RawImage2d of the image crate). The image crate is the most widely used library to load images and it works fairly well. The RawImage2d is basically just an array with pixel offsets.
• It should also be possible to create images from memory (i.e. for example notification bubbles / overlays - images that are generated on the CPU) by rendering them to an in-memory representation, then uploading them as a texture to the GPU / webrender somehow.
• Please take out the hard-coded /assets/ path. It only causes trouble with the working directory. The final applications can't run because it can't find the file for some icon because it was not started from the right directory.

[jaroslaw-weber]

you mean using texture as atlases? good idea.

we should get rid of assets path, yes. everything should be embedded inside the binary file, just like unity3d is doing it.

[fschutt]

It doesn't have to be embedded, but just give me control over where the images come from - from disk, from memory, from the binary, from a network ...

[christolliday]

I actually started working on loading from alternate paths a few days ago along with some other refactoring, the assets path was never intended to be used for any reason other than quick convenience.

For some parts of your proposal, the best way may be to implement it might be as an alternate draw state, at least for a start. Taking that approach you can implement it in an external application, source images from wherever you want, use your own resource management etc. I absolutely encourage people to do this by the way, that is, create components, work out the kinks then merge it back into the core if it makes sense.

As far as the optimization you are describing, before attempting anything like that I'd like to first perform some basic optimization of how webrender is used, and then have some basic benchmarks in place.

Anyway back to the main issue of hard coding paths, my plan is to replace image names in ImageState with an ImageDescriptor, and move the image loading parts of resources into a separate struct owned by resources called ImageLoader.

ImageDescriptor will be an enum that can store:

• a hardcoded path
• a relative path within assets
• a bundled image name
• a url (probably later)

ImageLoader then will let you:

• register an asset path
• register a bundled image and name it

[christolliday]

Made a PR, ended up going with ImageSource instead of ImageDescriptor