[Hitcher]

Do they apply to existing artwork or would one need to clear the database somehow?

No, you'll need to delete your textures folder and database for them to get rebuild.

Before you do that I'd install and run Artwork Dump so you have all the artwork downloaded and next to your videos ready for caching.

This is what I use for my setup with everything displayed on a 4K TV and all my artwork looks perfect.

xml:
<advancedsettings>

	<imageres>1080</imageres>

	<fanartres>1080</fanartres>

</advancedsettings>

[sarbes]

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?

Besides the performance and memory issues which makes it undesirable for most devices Kodi runs on, I'm also planning on removing GL/GLES mipmap support for Piers. But also, I don't believe that properly scaled texturing is much more difficult to implement.

[bossanova808]

Ok, thanks for the explanation.  I cross my fingers a proper implementation comes along!

[ashlar]

Besides the performance and memory issues which makes it undesirable for most devices Kodi runs on,

Couldn't the functionality be active just for platforms with enough computing power? And I'm asking this as a user that has transitioned to CoreELEC on Ugoos AM6b+ for the past few months, so it would probably not be useful for my main use case.

This is an improvement easily discernible with naked eyes, not some absurd superscaling algorithm that few can tell from what's currently available (I'm one of those few but I understand the difference). To "castrate" more powerful platforms doesn't seem a nice choice.

[sarbes]

Couldn't the functionality be active just for platforms with enough computing power?

That would be the case if this PR merges. But I won't work around just so this hack can keep functioning.

And I'm asking this as a user that has transitioned to CoreELEC on Ugoos AM6b+ for the past few months, so it would probably not be useful for my main use case.

I'd be surprised if such a device wouldn't display hickups.

This is an improvement easily discernible with naked eyes, not some absurd superscaling algorithm that few can tell from what's currently available (I'm one of those few but I understand the difference). To "castrate" more powerful platforms doesn't seem a nice choice.

To add a hack which prohibits performance improvements, just so that it would improve image quality in limited scenarios, would be the worse choice.

On top of that, I'm fairly sure I could come up with a good solution in the time it took me to come up with all the responses. I won't spend anymore time on this particular PR and the discussion around it. If someone is willing to implement texture scaling for real, I'd gladly guide them.

[ashlar]

On top of that, I'm fairly sure I could come up with a good solution in the time it took me to come up with all the responses. I won't spend anymore time on this particular PR and the discussion around it. If someone is willing to implement texture scaling for real, I'd gladly guide them.

Sorry, I did not want to irritate you. I was just trying to understand the reasoning behind choices.
Thanks for your explanation. I would surely appreciate better looking posters in Kodi on my Ugoos :-)

[sarbes]

There is https://github.com/xbmc/xbmc/pull/25630, which is far closer to a proper implementation. It needs to use existing infrastructure instead of bringing its own scaler, and some details need to be improved. But it has potential.

Edit: I know some of you are excited, but please refrain from posting in the PR if you don't find major issues. Let's just keep it about having a scaling step on texture upload. Sideline discussions unrelated to the actual code are just derailing the whole conversation.