+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Development (https://forum.kodi.tv/forumdisplay.php?fid=32)
+--- Forum: Skinning (https://forum.kodi.tv/forumdisplay.php?fid=12)
+--- Thread: Performance considerations when skinning (/showthread.php?tid=368525)
RE: Performance considerations when skinning - mikeSiLVO - 2024-09-19
(2024-09-19, 05:48)sarbes Wrote: To give you an update, the front to back rendering path has been merged, and is in an experimental stage.
Single and dual channel texture support has been merged. The packer for Piers will now reduce PNGs to more optimized texture formats. Make sure that unused texture channels are pure white, preferably disable the alpha channel and go for grey scale PNGs.
Compressed textures are next, which will add favourably to performance, while being virtually lossless in quality (for typical skin textures). This saves 50% of resources over the already optimized formats. If ASTC is used, the savings can exceed 75%, depending on the block size/texture content.
Can this be dumbed down for an idiot, like myself? I have no idea what I am doing in regard to image manipulation and have probably been using Gimp the wrong way from the get go...
I take an image and try my best to alter it to the way I need but I have no idea how my changes affect Kodi and its texture handling.
RE: Performance considerations when skinning - sarbes - 2024-09-19
It is easy for the most part. If you don't need the alpha channel, don't export the PNG with it. If you don't need colour, export with greyscale.
If you have just an alpha channel, you have to export the PNG as greyscale+alpha, as the file format doesn't allow otherwise. In this case, make the grey channel purely white.
If a uniform colour is wanted (for an icon or similar), use the diffuse colour with a alpha only texture instead of baking it into the texture. If you want to modulate the diffuse colour, you can do so by using a greyscale texture with optional alpha.
RE: Performance considerations when skinning - scott967 - 2024-09-25
This for now is about skinned xml windows in addons, but should be same as skins:
If we have a uniform background are you suggesting it should be ideally 1x1 and just use scaling in the control? 1x1 is invisible, so maybe something like 16x16 or 32x32 that you can see visually as a thumb? Likewise for a 1D gradient, 1920x1 but maybe 1920x32 so it can be seen? Always divisible by 4?
scott s.
.
RE: Performance considerations when skinning - sarbes - 2024-09-28
How is a 1x1 texture invisible?
A 1920x1 texture is way too much. The gradients I've seen would render fine with just a 16x1 gradient.
Textures can have arbitrary sizes, but should be limited to sensible resolutions.
RE: Performance considerations when skinning - sarbes - 2024-10-02
If https://github.com/xbmc/xbmc/pull/25775 lands, you don't have to mess with textures if you want generic gradients or a uniform color on a rectangle. It uses a texture size of 1-32 pixels, depending on the detail needed.
RE: Performance considerations when skinning - realcopacetic - 2024-10-04
(2024-10-02, 00:00)sarbes Wrote: If https://github.com/xbmc/xbmc/pull/25775 lands, you don't have to mess with textures if you want generic gradients or a uniform color on a rectangle. It uses a texture size of 1-32 pixels, depending on the detail needed.
This sounds very interesting as my skin ui is made up nearly entirely of a white 1*1 png and a few gradients, the tweezers for gradients looks very interesting as well. One reason I went bigger with my gradients was to avoid banding with a bit of noise, do you think this new element would avoid banding issues on gradients @sarbes
RE: Performance considerations when skinning - sarbes - 2024-10-05
You can go with dithered gradients, but those are usually resolution dependent. They are also not optimal for performance.
Often enough, the graphics hardware brings its own way of dithering. Most low-end hardware (i.e. most Android boxes) should come with hardware dithering
Shader based dithering is out of the question.