Providers know nothing about relative paths. They always work in absolute paths (relatives to their own base root).

'RaiseTextureChanged' must provide the same path that was used when previously loading the resource.

Hi Jesus,
thank you for the clarification!
Right, I'm always calling RaiseTextureChanged with the absolute path (starting with the / slash) as I don't keep the original Uri provided by NoesisGUI (I convert it to the file path and use it to asynchronously load the texture, then build an absolute Uri from this file path).
I've expected that the absolute path will always work. Hmm.

So, the problem is that when I use the relative path (Source="Images/Player.png") I get this output:

LoadTexture: UI/Controls/Game/Map/Images/Player.png

RaiseTextureChanged: /UI/Controls/Game/Map/Images/Player.png

For comparison, when I use the absolute path (Source="/UI/Controls/Game/Map/Images/Player.png") I get this output:

LoadTexture: /UI/Controls/Game/Map/Images/Player.png

RaiseTextureChanged: /UI/Controls/Game/Map/Images/Player.png

I think it will be better if the TextureProvider provided an identical path in the both cases for the sake of consistency.

Regards!

You are totally right, this should be fixed.

LoadTexture: UI/Controls/Game/Map/Images/Player.png
RaiseTextureChanged: /UI/Controls/Game/Map/Images/Player.png

I think this is happening because the XAML containing the texture has a URI that doesn't start with "/", for example: "Game/UI/Panel.xaml". If you change this to "/Game/UI/Panel.xaml" it should work. Relative texture URIs are just using the base URI of the XAML.

We normalize the URI as much as possible, but the first '/' is quite tricky to remove, because it changes the meaning of the path ("Game/UI/Panel.xaml" is a path relative to your provider, but "/Game/UI/Panel.xaml" may be interpreted as a global filesystem path.

Please, let me know if this makes sense to you.

Hi Jesús,
I thought about this but it doesn't make any sense to me regarding the TextureProvider—in particularly the part about "path relative to your provider".
As I see you're already resolving the path used in XAML: (as in my first example above)

XAML Source="Images/Player.png"

results in LoadTexture "UI/Controls/Game/Map/Images/Player.png" parameter

I think it will be correct (and perfect) if TextureProvider always receives an absolute path in the LoadTexture method (and so the same absolute path is provided on RaiseTextureChanged). So, just add the "/" prefix and voila, the issue is resolved!

Regards!

If the XAML is loaded with a 'prefix' (like for example /Game/UI/Panel.xaml) and it contains a "Images/Player.png", the texture provider should receive this uri = "/Game/UI/Images/Player.png". Could you verify this?

We can't add/remove automatically the prefix because it changes the meaning. Imagine I have my own provider with a root set at (/home/game/UI). If I receive a request for loading "Main.xaml" I will open the file at "/home/game/UI/Main.xaml" but if I receive the request "/Main.xaml" I should load (/Main.xaml, root of the filesystem, ignoring my root path).

Not sure if this is clear, I can train with a better example, but I first I want to understand if loading your XAMLs with prefix fixes the issue.

Hi Jesús!

I'm sorry for replying so late.

The issue was indeed related to the XAML loading without the prefix / (we always provided paths without it when loading XAML, including when loading UserControls). I was unaware of this nuance as in our case it made zero difference in practice. The only difference was related to the RaiseTextureChanged.

I've verified and everything related to XAML and Texture loading works exactly as you've described so there is no issue.

Please close this ticket.

Regards!
Vladimir

Thanks!

By the way, in 3.2.8 we implemented a few URI normalizations (like A//B.png -> A/B.png). More information in 0003765