Performance of panel views
#1
I've always found performance of panel views is much worse, I imagine because of how many art elements are being shown on the screen at once.

But given the power of modern hardware, I'm guessing (and could be way off) that the reason why it still seems to be a struggle, is that no matter what size we make the image controls, kodi's moving around the fullsize cached artwork that it has. 

I suppose the problem would be that we are using the same cached image for potentially fullscreen artwork as we are for tiny icons. 

My assumption for this is that I have a panel view where you can set how many items you see on the screen at once, going from this..

Image

to this...

Image

and performance tanks on small icons, even when I test on a pretty powerful PC with lots of RAM, I guess because on that machine I am importing artwork at 4K (as i sit a few inches away from the screen) and use the artwork full screen in a lot of places through the skin.

I'm not sure if there are ways of dynamicly creating different sizes of the cached image e.g. at least something like original, medium, small? How things like imgur work.

I guess this would also be a huge undertaking, so just wanted to see if it's something else anyone else feels strongly about or has any thoughts on - or if it's a complete non-starter.
Reply
#2
Probably also depends on any advanced setting used for artwork cache size.

I guess you could create new art types (eg fanart_medium and fanart_small), then resize and rename your fanart (fanart_medium .jpg and fanart_small.jpg) to match the sizes used in your skin. Then use those art types in the code for those view types.
Reply
#3
(2024-06-07, 16:38)Hitcher Wrote: Probably also depends on any advanced setting used for artwork cache size.

I guess you could create new art types (eg fanart_medium and fanart_small), then resize and rename your fanart (fanart_medium .jpg and fanart_small.jpg) to match the sizes used in your skin. Then use those art types in the code for those view types.

Yeah, in this instance it's probably just a me problem - I have advanced setting to cache artwork fullsize on this device because a) I thought it was powerful enough and b) I'm very close to the screen when I use it. With the normal settings panel performance is better (although still doesn't seem completely smooth 60fps during scrolls), however artwork looks blurry in other views. I'm shuddering at the thought of adding more custom art types, haha, it's already becoming a mission adding new items to my library with the existing ones I've got Big Grin
Reply
#4
I don’t know if you’re already using the line…

<preloaditems>…</preloaditems>

…in your panel container. I’ve found that it improves browsing a bit in some cases.
If I have helped you or increased your knowledge, please click the 'thumbs up' button to give thanks :)
Reply
#5
The texture system was not made for such varying element sizes. The texture cache should contain texture sizes close to their intended display size, but people often disable the size limit, or skins may display them at severely reduced size.

The result is that the GPU has to sample non continuously, which is poisonous for performance. The (often tiny) GPU cache is trashed and the shader cores stall a lot while waiting for new texture data. Even worse, the quality is severely reduced compared to a properly sized asset.

There is no straight forward solution at the moment. For example, just enabling mipmaps in GL/DX would lead to jank, and the memory requirements would be a no-go for 1GB devices.
Reply
#6
(2024-06-08, 02:09)manfeed Wrote: I don’t know if you’re already using the line…

<preloaditems>…</preloaditems>

…in your panel container. I’ve found that it improves browsing a bit in some cases.
Thanks yeah I have that enabled
Reply
#7
(2024-06-08, 12:18)sarbes Wrote: The texture system was not made for such varying element sizes. The texture cache should contain texture sizes close to their intended display size, but people often disable the size limit, or skins may display them at severely reduced size.

The result is that the GPU has to sample non continuously, which is poisonous for performance. The (often tiny) GPU cache is trashed and the shader cores stall a lot while waiting for new texture data. Even worse, the quality is severely reduced compared to a properly sized asset.

There is no straight forward solution at the moment. For example, just enabling mipmaps in GL/DX would lead to jank, and the memory requirements would be a no-go for 1GB devices.

Thanks for the technical explanation. I guess the issue is compounded by the fact that sizes on tmdb don't seem to be limited, so for example a lot of the landscape artwork that I would assume was intended to be more of a thumbnail than a full screen fanart is upkoaded there at 4k. Clearlogos up to several thousand pixels in width etc. I guess it's just something that more powerful devices can brute force to some extent.
Reply
#8
(2024-06-08, 12:18)sarbes Wrote: The texture system was not made for such varying element sizes. The texture cache should contain texture sizes close to their intended display size, but people often disable the size limit, or skins may display them at severely reduced size.

The result is that the GPU has to sample non continuously, which is poisonous for performance. The (often tiny) GPU cache is trashed and the shader cores stall a lot while waiting for new texture data. Even worse, the quality is severely reduced compared to a properly sized asset.

There is no straight forward solution at the moment. For example, just enabling mipmaps in GL/DX would lead to jank, and the memory requirements would be a no-go for 1GB devices.

Are there any advanced settings to play with, such as to increase GPU cache? Otherwise it looks like @Hitchers solution to use a different artwork type is the only viable solution.

I guess I wouldn't really be using fanart in panel containers anyway from what you're saying
Reply
#9
(2024-06-08, 15:51)realcopacetic Wrote: Are there any advanced settings to play with, such as to increase GPU cache? Otherwise it looks like @Hitchers solution to use a different artwork type is the only viable solution.
The GPU cache is part of your GPU. Other than replacing it, you can't influence cache sizes. See https://www.rastergrid.com/blog/gpu-tech...pu-caches/
Reply
#10
(2024-06-09, 00:56)sarbes Wrote:
(2024-06-08, 15:51)realcopacetic Wrote: Are there any advanced settings to play with, such as to increase GPU cache? Otherwise it looks like @Hitchers solution to use a different artwork type is the only viable solution.
The GPU cache is part of your GPU. Other than replacing it, you can't influence cache sizes. See https://www.rastergrid.com/blog/gpu-tech...pu-caches/

Ah right bit of a brain freeze there on my part! Apologies!!
Reply

Logout Mark Read Team Forum Stats Members Help
Performance of panel views0