Hi there!

I was wondering, with the list of resource shown below, are ALL of these resources paged into memory at application start-up? Or are they maintained in a cold state until needed? I'm wanting to make sure I don't do anything crazy, as I have about 350 of these images (game items) that can be loaded.

Hopefully I am not asking too many questions. I searched the docs and I'm having a hard time finding this. Is there an equivalent static property to UWP App.Current.Resources?

I was wondering, with the list of resource shown below, are ALL of these resources paged into memory at application start-up? Or are they maintained in a cold state until needed? I'm wanting to make sure I don't do anything crazy, as I have about 350 of these images (game items) that can be loaded.

So, I an world out of Unity, we only fully load textures when they need to be rendered but the header is always read to get metadata. So in that case, the 350 images would be scanned to get width and height and only those being rendered would be loaded.

In Unity, it is a bit different because we don't load textures, Unity is doing that for us. For that XAML, there will be 350 automatic dependencies to 350 Unity asset resources and I would say those textures are being loaded so I think it is better if you split that. Is that an option?

Hopefully I am not asking too many questions. I searched the docs and I'm having a hard time finding this. Is there an equivalent static property to UWP App.Current.Resources?

Honestly, the more questions you ask the better for everybody. If we are replying slowly these days it is because we are close to the final release. Don't worry about asking. 😃

We don't have support for reading back the global dictionary in Unity. You are in Unity right?

Yes, I am in Unity. Re: App.Current.Resources -- my current solution is to pass around references to the UserControl.

Regarding a resource dictionary with a large number of images -- the challenge is that I don't know which items a player will have in their inventory. They could have 0 or all 350. I haven't measured memory yet to see what the hit is. I understand I could use an atlas -- but in this scenario, I would be bringing in textures for items that are not necessarily in the player's inventory.

You should absolutely be using an image atlas for this sort of thing, and defining the brushes. I'm using 2 textures that have over 1000 128x128 icons split between them. For your item count, you can easily atlas them into 1 texture.

My Resource dictionary xaml has a bunch of entries like this
It's super easy to build an atlas in Unity from a folder full of textures.

@jswigart. Thank you for the suggestion. Square root of 1000 is 31.6. 31.6 x 128 is a 4096x4096 texture. Thanks for sharing this! So if I have approximately 400 at 512x512, that's 64 images per 4096x4096 texture. That makes sense!

To be clear, the benefit is mainly to reduce the number of textures, which should translate into drawing efficiency(reduced draw calls due to reduced material changes). It doesn't really reduce memory usage to atlas textures. In fact, it generally uses a bit more memory unless your textures fit into the atlas exactly. I'm not familiar enough with the rendering guts of noesis to know how big of an impact to draw call reduction and stuff you can expect, but I would hope that it is significant by atlasing unless the internals are doing something silly.

Yes, atlasing impact drawcalls in Noesis. Use them whenever possible, we are using them for example in our Inventory sample.

By the way, it is better, from the point of view of memory usage, to declare one ImageSource and reuse it in each image with a StaticResource. Even if you don't do this, the texture is always reused but you can avoid extra ImageSources being created.