Patches are welcome!

Hey, 
I have some code that does that (replacing nearest by linear scaling) and that I can merge.

Not sure if this should be done in SDL_SoftStretch() or in a new SDL_SoftStretchLinear() instead ?

Let's have a separate function for it, and add it after SDL 2.0.14 release?

If you want/need, I can test. :)

Ok, so this will be a new function.
The patch is straight forward and already tested for a while! 
I'll wait after 2.14 then,

Maybe we can still add the function for 2.14 release,
but bind with the SW Renderer after ?

IMHO that would be a very good decision.
Fedora, even rawhide (development branch)
still has 2.0.12 (which doesn't even have
the proper KMS rendering, which is in 2.0.13).
Waiting the adoption of 2.0.15 will take
many years!

Besides, the scaler code will only be activated
on user's demand (by the use of SDL_HINT_RENDER_SCALE_QUALITY
hint), which means the existing code will
unlikely to be affected.

I'll be very grateful if this landed in 2.0.14.
Because even then I'll likely have to wait
for an year or so...

We're in code freeze right now and are not adding any new features for release.

Stas, is there a reason you can't ship a custom SDL library with your project?

> Stas, is there a reason you can't ship a custom SDL library with your project?

I am not sure how can this be done.
Static linking?
Building sdl as an internal git sub-module?

Hmm, I can think of one work-around.
You can add SDL_SoftStretchLinear() that
will just call old SDL_SoftStretch() and
do nothing more (no new feature, no new code).
And I can re-define that function with
the new code from patch. If you build
libsdl w/o -Bsymbolic flag, the symbols
can be overridden.

So, I've added the SDL_SoftStretchLinear()
in https://hg.libsdl.org/SDL/rev/0c32de1a7fbf
(After splitting SDL_SoftStrech() in https://hg.libsdl.org/SDL/rev/e70a0440e99f )

you can give a try, it should quite fast since there are neon and see optimized routines.

maybe it won't compile because clang has issues with inline, so you need to mess with this define
https://hg.libsdl.org/SDL/file/0c32de1a7fbf/src/video/SDL_stretch.c#l447

I used pixman and SDL_rotozoom before, I end-up validating this code to pixel match pixman outputs.

It still need to be binded with the software renderer:
could be done easily with reading scale quality hint.
but the correct way should be to read the per texture scale quality field.
but SDL_LowerBlitScaled (in SDL_surface.c) doesn't transfer this information
 ... there is some renaming to do ... I won't do that right now.

Created attachment 4600 [details]
test app

Some test app to scale and interact with various parameters.
run with an image as a param, press h for help.

You can change rect size, position for src and dst surfaces, while scaling.

Oops forgot to run gendynapi.pl, thanks Ozkan !
https://hg.libsdl.org/SDL/rev/74ba009b45f5

clang, via sdl-ios-xcode build bot fails to compile SDL_stretch.c 
( https://buildbot.libsdl.org/#/builders/11 )
but on a real Mac with xcode 12 it compiles ?
how to fix it / which clang version the build bot use ?
https://hg.libsdl.org/SDL/file/0c32de1a7fbf/src/video/SDL_stretch.c#l447

> ... there is some renaming to do ... I won't do that right now.

I tried and also looked at the code, and
it doesn't seem like this new code is ever
called by the renderer, no matter of the
scaling hint.
Which is probably exactly what you say.
Just confirming.
Please ping when the renderer part can be tested.

Indeed, this isn't binded with the software renderer.

you can't test it manually here,
by changing the Strech to StrechLinear

https://hg.libsdl.org/SDL/file/3bea8b825fcd/src/video/SDL_surface.c#l917

Also, this only work with surface with BPP 32
(it can crash because the previous function allow 8/16/24/32 bpp, so it needs some manual check with format bpp field)

Scale mode is now forwarded to the software renderer: 
https://hg.libsdl.org/SDL/rev/02f670c66eed

But it only works with simplest blits (no blending), 32 bits, no ARGB2101010,
and the video output format should be same as the surface format.

Thanks, I can confirm that it works perfectly for me!
It doesn't even blur the default size when no scaling
is needed, which is very good (some other libs I tried,
blur the picture even if resize is not needed).

This all makes me quite motivated to try and fix #5341,
as SDL is really becoming very usable these days.
So lets see if I can do that...

Ok great so I marked this as fixed ! 
Just wondering, OpenGL isn't working x11 ?

marked as fixed

(In reply to Sylvain from comment #18)
> Ok great so I marked this as fixed ! 

I thought you would extend it a bit, for not only 32bpp,
to format conversion etc? :)

> Just wondering, OpenGL isn't working x11 ?

No, not for me.
I have a threaded renderer, which is a no-no with openGL.
Still waiting for SDL to support vulkan rendering. :)

ok :) so here's a fallback for other modes and formats:
https://hg.libsdl.org/SDL/rev/942819bd5deb
it uses an intermediate surface to do the linear scale, 
them do a non scale blit!

please give a try !

it's actually buggy because it doesn't handle format, so I'll rework that !

It wouldn't be straight-forward test for
me as I always use the native format for
speed-up. Of course I can make a hack or
2 to test the format conversion. :)

I have updated the fallback: 
 https://hg.libsdl.org/SDL/rev/5bab4dabaf08

but it's isn't fully tested. Yes please give a try with 
an non fast format, and with/without blending

I can see a few white-space errors in
your last patch.

I tried a few non-native formats (RGBA8888, RGB888, ARGB888)
and all seems well!

ok great, thanks.
I have also tested some various combination and paths.

fixed indentation in:
https://hg.libsdl.org/SDL/rev/19613ce246db

Created attachment 4626 [details]
test app

Improve the test app

For the record, 
add check for input format:
https://hg.libsdl.org/SDL/rev/0c1b34c8cb23

revert from bug #2687 and #3340
https://hg.libsdl.org/SDL/rev/1889c850fafc