Support .scale-XYZ images on WASM

[MartinZikmund]

What would you like to be added:

Currently images provided with multiple scales don't render on WASM at all:

For example with:

<Image Source="/Assets/Test.png" />

The rendered HTML contains just Test.png, although such image does not actually exist.

This can be resolved using the <img> srcset attribute, which allows us to specify multiple different scales for each image based on pixel density of the display.

Why is this needed:

Scaling on all pixel densities.

For which Platform:

• iOS
• Android
• WebAssembly
• Windows

Anything else we need to know?

[MartinZikmund]

I will try this

[MartinZikmund]

@davidjohnoliver Is there already a built-in way to find out all available .scale- versions of an image or should I implement it from the start?

[davidjohnoliver]

@MartinZikmund It's already implemented for the other platforms, you should be able to leverage the existing code: https://github.com/nventive/Uno/blob/5f7131f13b37a5a9809c5cac4b3208a13c549fd4/src/SourceGenerators/Uno.UI.Tasks/Assets/RetargetAssets.cs#L85

GitHub

unoplatform/uno

Build Mobile, Desktop and WebAssembly apps with C# and XAML. Today. Open source and professionally supported. - unoplatform/uno

[MartinZikmund]

@davidjohnoliver I was thinking about this and need a confirmation :-) . In case of WASM, I cannot just list all the items in the Assets folder, as the images are referenced "by URL" and when deployed, WASM can't see what's deployed as content file at the server.

This probably means I will have to create a build task (at the same level as RetargetAssets_v0), which will for example generate a list of all image assets in the project (could even be a simple text file), which will then be added to the project as EmbeddedResource, so that it can be later loaded in memory and checked to see if for a given image like "MyImage.png" actually exist its scaled/themed versions - "MyImage.scale-200.png" etc. Is this train of thought correct?

[davidjohnoliver]

@MartinZikmund Sure, it sounds like that approach should work.

[MartinZikmund]

@davidjohnoliver I just thought about one thing - this could potentially be a breaking change if the user calls assembly.GetManifestResourceNames() - normally it would be empty, but now there will be this custom embedded resource. Would this be ok?

[carldebilly]

We're already using it for a bunch of stuff, specially css and script files... it shouldn't be a problem.

[MartinZikmund]

@carldebilly Awesome, thanks!

[jeromelaban]

Implemented by #3694