Hey everyone,

Situation
within my current view, the animations stutter whenever I switch back and forth between the menus. I could identify that the loading of the necessary images causes this. And it isn't only stuttering the first time an image is shown. As far as I am aware, the usual fix would be to move the images to a shared resource dictionary to prevent the cleanup. But this isn't possible because the images are part of a ListBox and therefore the image's URIs are bound by a data model.
We talk about 6 - 7 PNGs, 380x620 in dimension, that are required to display the submenu.

I found a similar thread (https://www.noesisengine.com/forums/vi ... p?p=13268) where jsantos suggests implementing a custom TextureProvider. And this is what I have trouble with.

Asynchronous Texture Loading
I could get this to work quite well. The XAML is loaded and animates right away. Bigger images are missing for a split second but are filled in the moment they are done loading. The only issue is that NoesisAPI complains about the missing textures in the first place. It seems to expect images in a synchronous manner:

Error loading 'images/btn_xyz.png', using fallback texture

In my current implementation, ITextureProvider::GetTextureInfo initiates the async texture loading, reads the texture's dimensions, and creates and returns the resulting Noesis::TextureInfo. In the background, the images are loaded on a different thread and whenever this job is done, TextureProvider::RaiseTextureChanged is called, which updates my view correctly.
So far so good. Stepping through the code, NoesisAPI calls TextureProvider::GetTextureInfo, first, whenever the XAML tries to load an image. I assume that this resulting TextureInfo object is not only used to reserve space in the layout but also serves as a validity check for the texture. Whenever I return actual dimension data, it expects to be able to display the image, which it can't given that the async texture loading process has just started.

So, how do I prevent this error? I only want to reserve space in the layout and want to rely on calling RaiseTextureChanged to actually provide the image.

I assume this is happening because you are returning a null texture in the first request. What happens if you return a 1x1 black texture for example? That should work

Yes, it actually works. By returning a default texture, there is no Error Output anymore. Nevertheless, I can see this black texture for a split second now. Is your original fallback texture a transparent pixel? Would it hurt the performance when I return a transparent pixel?

Edit: I've tried a transparent pixel and it turns out to be rendered all white in the game. Any magic I am missing here?

We are using premultiplied alpha in our textures, make sure to return a #00000000 color in your texture.

Yes, thanks for the hint. There was something wrong with my pixel and our technical artist provided me with a proper one :)

Great to know you fixed it! :)