[ashlar]

I have seen this pull request: https://github.com/xbmc/xbmc/pull/25497 and I see there's contrasting view on it.

Since I did not want to pollute Github with "regular" discussion, I thought about opening one here.

Is the pull request just for x86 platforms? From what I've read there I think so but maybe I'm wrong. On the current Ugoos AM6B+ I use, posters with writing on them get scaled really badly so I understand the need for this.

As a bit of context, here's a picture that nicely summarizes what this is all about:

[ashlar]

I'd like to have @axbmcuser participate here, since he's the author of the pull request.

[Hitcher]

posters with writing on them get scaled really badly

Have you tried any of the advanced settings scaling options?

https://kodi.wiki/index.php?title=Advanc...ry_artwork

[ashlar]

posters with writing on them get scaled really badly

Have you tried any of the advanced settings scaling options?

https://kodi.wiki/index.php?title=Advanc...ry_artwork

Since what release have these been available? I also imagine that axbmcuser was familiar with them when they did their pull request, so maybe they do not solve the problem at hand?

But thanks for this, I'll surely test them. Do they apply to existing artwork or would one need to clear the database somehow? Does one need to use Texture Cache Maintenance utility, which I had no particular luck in trying last time I tested?

[roidy]

@ashlar Unfortunately Kodi's GUI scaling has always been bad, and no amount of advancedsettings texture cache scaling options is going to fix the fact that once the GUI reads the texture from the cache it further scales it to the size the skin needs using a poor nearest neighbour scaling method.

This issue was first talked about way back in 2014 and 10 years later there's still been no real solution, so I wouldn't hold your breath for a fix.

https://forum.kodi.tv/showthread.php?tid=200401

[sarbes]

@ashlar Unfortunately Kodi's GUI scaling has always been bad, and no amount of advancedsettings texture cache scaling options is going to fix the fact that once the GUI reads the texture from the cache it further scales it to the size the skin needs using a poor nearest neighbour scaling method.

No. The explanation why posters and other assets look like this is totally wrong.

Kodi doesn't scale cached images on upload. The GPU scales the texture via linear sampling. There is no nearest neighbour scaling anywhere.

[roidy]

@ashlar Unfortunately Kodi's GUI scaling has always been bad, and no amount of advancedsettings texture cache scaling options is going to fix the fact that once the GUI reads the texture from the cache it further scales it to the size the skin needs using a poor nearest neighbour scaling method.

No. The explanation why posters and other assets look like this is totally wrong.

Sorry meant to say "once the GPU reads the texture from the cache" instead of GUI.... So not totally wrong just one word.

The GPU scales the texture via linear sampling. There is no nearest neighbour scaling anywhere.

Linear sampling or nearest neighbour it still results in textures that look really bad.

[sarbes]

Linear sampling or nearest neighbour it still results in textures that look really bad.

No, that's also not true. Linear scaling can look quite okay. The issue stems from not sampling continously. Even more elaborate scalers will look bad in this case.

[roidy]

Linear scaling can look quite okay.

But it clearly doesn't look ok in Kodi's case  

The issue stems from not sampling continously.

So I guess the question is why doesn't Kodi sample continuously?

[sarbes]

So I guess the question is why doesn't Kodi sample continuously?

Because the texture is often too large to do so.

[roidy]

Because the texture is often too large to do so.

I currently use advancedsettings to cache textures at double the resolution that the view I use most often renders it's posters at so there is less scaling. The results while not perfect are pretty good.

I tried caching them at the exact resolution the posters are in the skin but they end up looking really soft like the GPU is still scaling them even though no scaling should be needed.

[sarbes]

I tried caching them at the exact resolution the posters are in the skin but they end up looking really soft like the GPU is still scaling them even though no scaling should be needed.

There is no way that the GPU will degrade the texture in such a way, if the texture is at the size it is displayed at.

Look, I feel that there are a lot of misconceptions about the way how image/texture handling is done. The whole topic is pretty conflated. Such anecdotal claims as above would need to be backed up by evidence.

From what I can see in the code, Kodi has never been set up for the stark difference in size of the source image to the UI element. It was expected that the source image could be used almost directly as texture for a similarly sized element. But a lot of skins were designed without this fact in mind.

[ashlar]

But why do axbmcuser examples look so much better? See pic in the opening post.

[sarbes]

But why do axbmcuser examples look so much better? See pic in the opening post.

Because it uses mipmapping.

[bossanova808]

So the question is - why not let through a benefit from a tangible improvement - that is just ~10 lines of code - for now?  What are the negatives of this that is holding this back...or is it just perfect/theoretical being the enemy of good?

I definitely don't properly understand the core Kodi code path issues, but this seems an obvious visual improvement, apparently does not have any real risk/penalty attached....and sure, there might well be a better way, but that's just not currently on the table. 

So...why not this in the meantime?  It's not like these 10 lines form a massive ongoing maintenance burden, right?  And scaling quality has truly been an easily observable issue with Kodi...forever.   For a media presenter/player, I'd have thought an improvement in this area would be welcome. Obviously my opinion is basically meaningless here, but it doesn't feel like a really good reason, other than 'there's an in-theory better way', has been given for blocking this.