Memory and Performance Implications of a Large Resource Dictionary
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.

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.

Re: Memory and Performance Implications of a Large Resource Dictionary
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?
Re: Memory and Performance Implications of a Large Resource Dictionary
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.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.
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?
Re: Memory and Performance Implications of a Large Resource Dictionary
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. 😃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?
We don't have support for reading back the global dictionary in Unity. You are in Unity right?
Re: Memory and Performance Implications of a Large Resource Dictionary
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.
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.
Re: Memory and Performance Implications of a Large Resource Dictionary
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.
My Resource dictionary xaml has a bunch of entries like this
Code: Select all
<ImageBrush x:Key="arc_spawner_item" ImageSource="/Assets/Art/Environment/atlas_generation/item_source/atlas_01_base/CVItemIcons00_base.png" Stretch="Fill" ViewboxUnits="Absolute" Viewbox="1536, 3968, 128, 128"/>
Re: Memory and Performance Implications of a Large Resource Dictionary
@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!
-
- jswigartPlayful
- Posts: 5
- Joined:
Re: Memory and Performance Implications of a Large Resource Dictionary
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.
Re: Memory and Performance Implications of a Large Resource Dictionary
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.
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.
Code: Select all
<ImageBrush ImageSource="{StaticResource Image.IconAtlas}" Stretch="Fill" ViewboxUnits="Absolute" Viewbox="{Binding Item.Icon}"/>
Who is online
Users browsing this forum: No registered users and 0 guests