[sarbes]

In other news, please see that your textures are properly authored. Omega is be able to support single/dual channel textures, if some other work I'm doing lands. If your textures are properly done, the texture packer can create optimized textures out of PNGs.

There will be additional texture formats introduced. Luma (L), alpha (A) and luma+alpha (LA). Those textures use only 25-50% of memory resources, compared to the current RGBA format.

The texture packer can optimize textures in the following cases:
- If the color channels are white for the whole texture, it is stored as an alpha only texture
- If the texture color is greyscale without alpha, it is stored as a luma texture
- If the texture color is greyscale with alpha, it is stored as a luma+alpha texture

Keep in mind the following:
- Use a pure greyscale PNG if you want to quarantee it to be a luma texture
- Use a greyscale+alpha PNG if you want to guarantee it to be a luma+alpha texture
- Make the whole greyscale channel white (even transparent pixels!) if you want it to be an alpha texture
- Use diffuse colours and such optimized textures if possible
- Don't use indexed PNGs (they decode to LA instead of L in case of Estuary)

In case of Estuary, we can reduce the memory footprint of all textures from around 65MB to 20MB, as most of the textures are "alpha only" (icons and such). Over 80% of all its textures have no information in the colour channels.

[Hitcher]

@sarbes Unfortunately I don't understand what any of that means as I'm a complete noob when it comes to graphics. If you have time could you look at the textures I use in my skin and point me in the right direction to optimise them.
https://github.com/HitcherUK/skin.ftv
Thanks.

[sarbes]

First of all, I would move all those large weather backgrounds out of the texture file, it is ~70MB! Loading out of this file is happening synchronously as far as I'm aware. Loading huge texture chunks will stall out main thread on low-end systems (i.e. it will stutter). Having them in the "extras" folder enables them to load asynchronously to some extend. Maybe you could reencode them, as 100-150kB per 1920x1080 should be enough. You could probably save half of the data size by doing that.

You have to keep in mind that all the textures of the texture.xbt are just lightly (and losslessly) compressed. Just the weather textures alone will occupy 480MB in size. Estuary on the other hand, has a 1.2MB texture file, which unpacks to 65MB (20MB with optimized textures).


A lot of textures (like "DefaultActor.png" and alike) are not uniformly colored (most of them seem to have a blue hue), making them unsuitable for luma-only textures. If you want to benefit from single channel textures, you should convert them to greyscale, and add the hue via a diffuse color.


There are also instances where you have menu structures as complete textures. Such menus should be constructed out of multiple elements. For example, the menu of "category_back_list.png" could be made out of 4 different textures:
- The grey header (with a 1x1 pixel texture)
- The left hand surface (with the same 1x1 texture, but with another diffuse color.
- The gradient with a 32x1 texture
- And the gradient, using the same 1x1 texture as before

Right now, this element as a whole is using 2.8MB of GPU RAM. Loading it might lead to a dropped frame. Displaying it at 60fps occupies a texture bandwidth of over 166MB/s. You could optimize this texture even for Nexus.

As you skin is quite slim, it is not too critical. But is is something to keep in mind when designing new elements. As an easy fix, you could have textures such as "addon_browser_back.png" slimmed down to a 1D texture (e.g. going from 558x480 to just 1x480) if you don't want to re-engineer your skin elements.


Files like "icon_addons.png" are not greyscale, despite looking like they are. There are some minute differences in the RGB values, so they can't be stored as LA textures.


Everything in the "shutdown" folder has weird colors. It can be encoded into LA textures, despite only the alpha channel being relevant. This texture will be experiencing grey fringing, as the surrounding color is bleeding through. You should set the color values to pure white.

[jurialmunkey]

@sarbes

Do the channel benefits also apply for unpacked textures or only packed ones?

I keep some pngs like user selectable icons outside of the xbt in extras to allow users to select them for customisation. Wondering if there's any benefit to convert these to dual channel (white icons on transparent background).

slimmed down to a 1D texture (e.g. going from 558x480 to just 1x480)

Isn't there a minimum width we need to use (4px or 8px from memory) to ensure textures packed correctly and displays properly on 4k? Or does that no longer apply?

[Andrea1998]

You can test it with Omega as soon as the patch lands. We are still ironing out some issues.

Thanks, I will wait for the official stable arrival of Kodi 21 Omega, hoping the patch will be implemented.

Meanwhile, I leave active the parameter in advancedsettings.xml <fronttobackrendering>true</fronttobackrendering>
hoping it doesn't cause problems.


May I ask about this, how can I optimize Confluence?

Are the textures like ContentPanel.png and the various panels already in grayscale, or should all of them be re-edited to get the benefits of Kodi Omega?

In the meantime, can I do something, trying to optimize this "bubble" effect, remove some texture, or has everything already been done?

(I use this skin with the nvidia shild pro, I still hope to be able to optimize it in some way)


Thank you for your help

[sarbes]

For Confluence, various elements don't qualify for the "lean" textures, as they have minuscule color variations despite appearing greyscale. I can't see them (but this monitor is also not made for any graphics work). You could convert them to true greyscale textures.

The blade menus use pretty large textures. Only the "shiny" part at the edges need detail, the part has a uniform color. You could reduce the texture sizes.

The lower gradient could be made opaque.

I would think about making the blade menus (info and left side element) opaque, so that everything below is occluded.

[sarbes]

Isn't there a minimum width we need to use (4px or 8px from memory) to ensure textures packed correctly and displays properly on 4k? Or does that no longer apply?

I don't see why. There was a texture compressor in place, which long gone. If you can point me to an issue, I would look into it.

Even Confluence features some 1D textures.

[Andrea1998]

For Confluence, various elements don't qualify for the "lean" textures, as they have minuscule color variations despite appearing greyscale. I can't see them (but this monitor is also not made for any graphics work). You could convert them to true greyscale textures.

Ok really thank you, I'm trying to make the textures in true grayscale, using photoshop cc, could you please tell me if how I exported them is the correct way to have true grayscale textures?

Is this export with these parameters correct?

Step 1: https://imgur.com/a/aserUiy

Step 2: https://imgur.com/a/n4y2sB2


In this way, can the textures now be qualified as "lean", i.e. suitable for the new optimized channels of kodi 21 Omega?
(trying to get a luma+alpha texture, LA )

I really thank you for your help 🙏

[jurialmunkey]

Isn't there a minimum width we need to use (4px or 8px from memory) to ensure textures packed correctly and displays properly on 4k? Or does that no longer apply?

I don't see why. There was a texture compressor in place, which long gone. If you can point me to an issue, I would look into it.

Even Confluence features some 1D textures.

No issues directly, just something I've been told to correct in the past when submitting to the official repo.

Wiki lists minimum dimensions as 4x4 so it must've been necessary at some stage (though I'm sure this wiki page is also massively out of date).
https://kodi.wiki/view/Texture_Attributes#TexturePacker

[Andrea1998]

@sarbes

Could you recommend me a better program than Texture Tool (https://kodi.wiki/view/TextureTool) to pack textures?
(I would like to use it to improve kodi performance speed)


Thank you for your help.

[jurialmunkey]

@sarbes

Could you recommend me a better program than Texture Tool (https://kodi.wiki/view/TextureTool) to pack textures?
(I would like to use it to improve kodi performance speed)


Thank you for your help.

There is no other tool. Texture Tool is just a gui for Texture Packer which is Kodi's internal tool to pack textures.

If you pack textures into xbt then you get better performance because it changes the textures to match Kodi's internal format. That allows kodi to read the texture directly rather than needing to convert it first.

[sarbes]

@sarbes

Could you recommend me a better program than Texture Tool (https://kodi.wiki/view/TextureTool) to pack textures?
(I would like to use it to improve kodi performance speed)


Thank you for your help.

There is no other tool. Texture Tool is just a gui for Texture Packer which is Kodi's internal tool to pack textures.

The GUI thingy seems unmaintained. The last commit was three years ago (not that we had much code changes in our packer, but still...). Kodi's texture packer will be the way forward, especially for all the new formats.

If you pack textures into xbt then you get better performance because it changes the textures to match Kodi's internal format. That allows kodi to read the texture directly rather than needing to convert it first.

That's only partially true. Yes, you get lower load times because the file is in RAM and only lightly compressed, but that's it.

A huge drawback is the synchronous nature of this texture loader. In order to guarantee the availability of the texture, all other GUI operations (on CPU and GPU) are halted until the texture has been decompressed and uploaded. This might result in 1-2 frames of freezes. Optimizing the textures will reduce this, but it won't eliminate the root cause.

In the future, I hope to optimize the loading behaviour. The synchronous loader should go away in favour of permanently uploaded textures (if memory permits it).

Right now, the async (background) loader also blocks the system when uploading to the GPU. But for GL/GLES I'm experimenting with having all of the process done without any disruption.

TL;DR the XBT file is not so much about performance, but about texture loading. If you can live with a loading delay, don't put the texture in an XBT (at the moment).

[jurialmunkey]

The GUI thingy seems unmaintained. The last commit was three years ago (not that we had much code changes in our packer, but still...). Kodi's texture packer will be the way forward, especially for all the new formats.

It was actually updated in Jun 2021 for some Texture Packer changes - it's just the github "source" folder that's not updated, only the releases page:
https://github.com/e0xify/KodiXBMCTextur.../tag/2.9.2

I don't think it's been updated since then though because there haven't been any changes to TexturePacker

As far as I can tell it still works. I used it a few months ago without any issue.

A huge drawback is the synchronous nature of this texture loader. In order to guarantee the availability of the texture, all other GUI operations (on CPU and GPU) are halted until the texture has been decompressed and uploaded. This might result in 1-2 frames of freezes. Optimizing the textures will reduce this, but it won't eliminate the root cause.

Oh this is really interesting info. Thanks for the explanation.

I had no idea that there was a scenario where an xbt could have *worse* performance than plain pngs.

I had always assumed that the sync loader (ie background=false) worked the same for xbt or png. I'd thought pngs just had an added step of first needing conversion to the internal format used in xbt which would mean pngs always perform slightly worse (when not background loaded). Really interesting to find that this is not necessarily the case.

[scott967]

So I think the wiki currently says textures for texturepacker must be argb 32 bit.  Will texture maps with greyscale work in existing texturepacker or is there / will be a ver 21 compliant texturepacker?  Is there some sort of support for 1-bit alpha?  In a prior life I only used that in DXT-1 dds textures, not sure how to do that in jpg/png?

scott s.
.

[realcopacetic]

For Confluence, various elements don't qualify for the "lean" textures, as they have minuscule color variations despite appearing greyscale. I can't see them (but this monitor is also not made for any graphics work). You could convert them to true greyscale textures.

Ok really thank you, I'm trying to make the textures in true grayscale, using photoshop cc, could you please tell me if how I exported them is the correct way to have true grayscale textures?

Is this export with these parameters correct?

Step 1: https://imgur.com/a/aserUiy

Step 2: https://imgur.com/a/n4y2sB2


In this way, can the textures now be qualified as "lean", i.e. suitable for the new optimized channels of kodi 21 Omega?
(trying to get a luma+alpha texture, LA )

I really thank you for your help 🙏

Be careful with Photoshop. Exporting a PNG as grayscale is likely to convert it back into an RGB at the export stage. Same with Save for Web. You need to use Save and then choose smallest (slowest) for the ideal grayscale image. https://community.adobe.com/t5/photoshop...p/12656783