Performance considerations when skinning
#31
Copacetic

Right, this one is as minimal as it can get. I guess this can run even on lower tier platforms at 4k. But there are still some adjustments you can make.

On the info screen, there is a black fullscreen rectangle rendered behind the fanart. This could be optimized away.

The left hand settings menu draws a faded texture across the screen. You could try to dim all elements below with just one diffuse fade.

From what I can tell, you seem to dim fanart at the info screen by using transparency. You can get the same effect by using a diffuse color with solid alpha.*

The pink selection rectangle in the grid view could be done in one go, using a bordered image with disabled infill. This would eliminate three draw calls. But that's negligible.

Otherwise, I see some geometry outside of the screen. The GPU won't render it, but this also uses tiny bits of CPU resources. Also negligible.

The bold letters of a selected item are drawn twice. Once almost totally transparent, and then proper. I'm not sure why, you would have to investigate this. Not totally dramatic.**


Technical explanations

*By avoiding transparent surfaces, desktop GPU's won't have to read the previous screen content to blend the texture. Depending on the circumstances, this can save 1/3 of the memory BW.

**With Nexus, Kodi will not draw elements below 1% visibility. But this is just on the GPU side of things, so any GUI engine overhead still occurs.


Renderdoc

I can't give you much advice here. Maybe try a nightly or make a bug report.
Reply
#32
(2022-07-06, 19:14)sarbes Wrote: Copacetic
...

Thanks @sarbes - I really appreciate the feedback.

Default is pretty minmal, yeah. It gets a bit heavier if you turn on thet embedded lists (for showing seasons within the tvshows view etc) or multiart. The idea of the skin has always been to keep as much focus as possible on the artwork.

Info screen - thanks I fixed this, removing the black rectangle and using a fadediffuse to animate the changing opacity of the fanart based on which content is visible. I now have:
xml:

<control type="image">
  <!-- 25% brightness-->
  <animation effect="fadediffuse" end="ff404040" time="0" condition="true">Conditional</animation>
  <aspectratio>scale</aspectratio>
  <texture background="true">$VAR[Dialog_Info_Background]</texture>
</control>

Does this avoid the issue of transparent surfaces?

Left hand settings menu - yes I was thinking about making this switch, at least for the default dark theme. For the light theme, I think I need to keep the overlay unless we have in future the ability to animate the backgroundcolor of the window, as I need the white background to dim when the menu is visible. A question also on this one: Let's say I have an artwork on the screen which I've dimmed to 25% with the following animation:
xml:
<animation effect="fadediffuse" end="ff404040" time="0" condition="true">Conditional</animation>

Now, when the left hand settings menu or shutdown menu is showing, I want this to fade from 25% to 15%. So as I understand it, On top of the above animation, I can add a second and they will stack:
xml:
<animation effect="fadediffuse" end="ff9a9a9a" time="360" tween="sine" easing="inout" reversible="true" condition="xyz">Conditional</animation>

I just need to consider that this second animation is relative to the first, so to get from 25% to 15%, I need to dim the image by around 60%. This works where I've tried it... but my question is, is it ok to stack these animations in this way or is there a more efficient way to have the same effect (artwork with a brightness of 25% that then smoothly drops to about 15% when the menu is visible on top. Previously I would do this with an overlay layer).

Pink selection rectangle, geometry off screen, bold letters of slected item drawn twice - these are mainly hacks to get around the constraints of the skinning engine. The rectangle for example, I need to be able to have appear outside of the boundary set by the focuseditem, so I do it with a slide animation. And the label being drawn twice is because I can't have a grouplist within my focusedlayout so I use a blank label to get the placing right in order to have something like this 'Label 1 of variable length' / 'label 2'. But thanks for pointing these out. I'll revisit them and see if there's a better way!
Reply
#33
@sarbes ,

have made all of the major changes you have suggested and a number of minor ones as well. I have tried using Renderdoc to see what the results of the optimisations were but keep seeing issues with the saved captures. I submitted a error report to the Renderdoc author who replied back that the log files suggested there was an issue with the program (Kodi). Now that would be way beyond my pay grade, but might be somewhat closer to yours. Would you benefit from seeing the message and log file? PM me and I can send it your way.

Just as a bit of background, my system is a 4570 i5, 16G of ram and a GT630 running Windows 10, so possibly related to DX11 issues.

Wyrm
Reply
#34
Hey. I was a bit busy in the last few months. Is there something new you guys like to ask?

In other news, I would strongly suggest to go for opaque surfaces if you can (no alpha in the texture, or in the diffuse color). With https://github.com/xbmc/xbmc/pull/22919 (click for more info), we will have front to back rendering on OpenGL/GLES - so every system except Windows. Kodi will render all opaque elements in a first pass, front to back. Elements with partial transparency will be rendered back to front. All areas covered by opaque elements will be culled by the GPU, reducing the overdraw. In some cases, I've seen improvements of up to 50% reduction in used GPU resources.
 
(2022-07-20, 16:08)wyrm Wrote: have made all of the major changes you have suggested and a number of minor ones as well. I have tried using Renderdoc to see what the results of the optimisations were but keep seeing issues with the saved captures. I submitted a error report to the Renderdoc author who replied back that the log files suggested there was an issue with the program (Kodi). Now that would be way beyond my pay grade, but might be somewhat closer to yours. Would you benefit from seeing the message and log file? PM me and I can send it your way.

Sorry, I can't help you with Renderdoc.
Reply
#35
@sarbes wow this sounds great.

Since I'm on Windows and can't test myself, I'm wondering how partially opaque textures get treated?

I'm specifically thinking buttons or poster diffuses etc with rounded corners. Does the centre part of the texture which is opaque still gain this benefit, or will the corner having some transparency mean the whole texture is treated as not opaque in term of rendering.

I guess what I'm asking is: is it per pixel or per texture? (from my understanding it is the latter but want to make sure I have it right).
Arctic Fuse - Alpha now available. Support me on Ko-fi.
Reply
#36
@sarbes

In a poorly performing device it is better to use a default skin (Estuary) or a light skin example: Confluence?

Or is the difference subtle?



Thanks for your help
If i helped you, you can thank me with a thumbs up 👍 below, thanks 🙏.
Kodi stable release | Skin Estuary (by phil65)
I like editing skins ❤
Reply
#37
(2023-03-09, 01:12)jurialmunkey Wrote: I'm specifically thinking buttons or poster diffuses etc with rounded corners. Does the centre part of the texture which is opaque still gain this benefit, or will the corner having some transparency mean the whole texture is treated as not opaque in term of rendering.

I guess what I'm asking is: is it per pixel or per texture? (from my understanding it is the latter but want to make sure I have it right).
An element is not opaque if one of the following is true:
- The texture has an alpha channel 
- The diffuse texture has an alpha channel
- The alpha of the diffuse color is not 0xFF

I guess one improvement on top of this would be a hint for the GUI engine, similar to the "infill" argument. Marking the core or the even the "cross" of the 9-slice element as solid should work pretty well. You could have a similar effect now if you draw the 9-slice with infill disabled, plus a simple opaque box in the middle.

Also, I have the idea of providing a fallback color to which the primary texture can be blended to. This would allow the engine to treat the element as opaque, even if the texture has an alpha channel.

Keep in mind that opaque elements are already better for performance on desktop GPUs. If an element is opaque, only its pixels have to be written back to main memory. Else, the previous content has to be read from main memory, blended with the pixels of the element, and then can they be written back (all assuming that there is no caching or other trickery). Any improvements here will benefit Windows too, but not as much.

(2023-03-11, 20:36)Andrea1998 Wrote: In a poorly performing device it is better to use a default skin (Estuary) or a light skin example: Confluence?

Or is the difference subtle?

I'd be hesitant to call Confluence light, now that I analyzed it a bit while I was writing the patch. It too has some GPU intensive scenes (in particular the info screen on top of movies). Also it keeps the "bubble" texture in the background at all times, rendering fanart on top. The patch will reduce the waste considerably, but it can't optimize the way the skin is designed.

FTV is the lightest skin I know, with just very few places for optimization.

A skin which benefits greatly from front to back rendering is Unity. It has lots of opaque elements and very few alpha transitions. It could be improved here and there, but it seems to offer a constant experience.
Reply
#38
(2023-03-11, 22:59)sarbes Wrote: Also it keeps the "bubble" texture in the background at all times, rendering fanart on top. The patch will reduce the waste considerably, but it can't optimize the way the skin is designed.

What exactly are you referring to by the term "bubble"?
Also what patch are you referring to?

Forgive my ignorance...

However, it was just an example to try to understand if it was better a default skin already pre-installed, or a lighter one to apply on top?


Thanks for your help.
If i helped you, you can thank me with a thumbs up 👍 below, thanks 🙏.
Kodi stable release | Skin Estuary (by phil65)
I like editing skins ❤
Reply
#39
@sarbes
You read my mind about where I was going re the infill. I think that would be useful, as a lot of the textures I use are otherwise opaque except for the corner rounding on the diffuse.

In tandem with the other PR adding the border attribute for diffuse textures, it would allow for a lot of optimisation in skins going for the rounded corner look.
Arctic Fuse - Alpha now available. Support me on Ko-fi.
Reply
#40
(2023-03-11, 23:30)Andrea1998 Wrote: What exactly are you referring to by the term "bubble"?
The default background texture you see when starting Confluence is always drawn to the screen, even if fanart is covering it.

(2023-03-11, 23:30)Andrea1998 Wrote: Also what patch are you referring to?
The one I've mentioned in my post before: https://forum.kodi.tv/showthread.php?tid...pid3144709

(2023-03-11, 23:30)Andrea1998 Wrote: However, it was just an example to try to understand if it was better a default skin already pre-installed, or a lighter one to apply on top?
Define better. If you like a skin which runs with acceptable performance on your device, it is a good option.
 
(2023-03-12, 02:19)jurialmunkey Wrote: @sarbes
You read my mind about where I was going re the infill. I think that would be useful, as a lot of the textures I use are otherwise opaque except for the corner rounding on the diffuse.

In tandem with the other PR adding the border attribute for diffuse textures, it would allow for a lot of optimisation in skins going for the rounded corner look.

 I hope that I can pump out as much as I can. I won't have much time next month.
Reply
#41
(2023-03-12, 13:43)sarbes Wrote: The one I've mentioned in my post before: https://forum.kodi.tv/showthread.php?tid...pid3144709
Ok, thanks, sorry but I hadn't noticed everything well.

Does this patch also work with android tv box devices like Nvidia shield tv box pro?

I would like to implement this patch, but forgive me I can't figure out how to do it in an android tv box device, if it would be possible to do it, can you explain all the steps better?


I really thank you 🙏
If i helped you, you can thank me with a thumbs up 👍 below, thanks 🙏.
Kodi stable release | Skin Estuary (by phil65)
I like editing skins ❤
Reply
#42
@sarbes

Ok, I think I understand what to do:
- I download the files from here: https://github.com/xbmc/xbmc/tree/62ed24...6a6ec0e859
- I replace the downloaded files to the original files in -> Android/data/org.xbmc.kodi/files/.kodi
- Change advancedseting.xml to <fronttobackrendering>true</fronttobackrendering>


Everything is correct?
(Forgive me but it's my first time)


Will this change then be added to the xbmc master files?
(https://github.com/xbmc/xbmc)


Thank you so much for your help.
If i helped you, you can thank me with a thumbs up 👍 below, thanks 🙏.
Kodi stable release | Skin Estuary (by phil65)
I like editing skins ❤
Reply
#43
(2023-03-14, 01:42)Andrea1998 Wrote: - I download the files from here: https://github.com/xbmc/xbmc/tree/62ed24...6a6ec0e859
- I replace the downloaded files to the original files in -> Android/data/org.xbmc.kodi/files/.kodi

Everything is correct?
(Forgive me but it's my first time)

No, that is not correct.

C++ code must be compiled into a program (ie into Kodi) for the platform in order to be used.

If you do not know how to compile code and no one has made a precompiled test build available for your platform, then you cannot use the PR until it goes through code review and is merged into main.

Once a PR is merged then you can test it as part of the nighties.

There are instructions on Kodi github about building/compiling. It is way out of the scope of this thread to teach you how.
Arctic Fuse - Alpha now available. Support me on Ko-fi.
Reply
#44
@jurialmunkey

Thanks for answering me, I don't think Sarbes would have answered me again.

Now I understand, no I don't need to compile it, so I will wait for a next Kodi release, but installing only the stable ones I hope this feature will be added in a future stable kodi release (example 20.2)

It's a very cool feature that I'd like to see implemented soon.


Thanks again for replying and clarifying my ideas.
(if I can help you in any way, as always +1 and I will make a donation soon for all the work you do)
If i helped you, you can thank me with a thumbs up 👍 below, thanks 🙏.
Kodi stable release | Skin Estuary (by phil65)
I like editing skins ❤
Reply
#45
You can test it with Omega as soon as the patch lands. We are still ironing out some issues.
Reply

Logout Mark Read Team Forum Stats Members Help
Performance considerations when skinning0
This forum uses Lukasz Tkacz MyBB addons.