Suggestion 1 is the same comical hack I already mentioned should be disregarded as a sincere approach.
Suggestion 2 is avoiding confronting the statement at hand that ‘SDL does not implement this adequately’
Suggestion 3 is inefficient on multiple basis of both processing time and extra allocations of memory - it is merely an attempt to hack SDL to do this from the outside, which is why it suffers from these set backs which are more than minor in their side effects.
All 3 of these are inadequate answers to avoid confronting the issues at hand, and seeing the flaws in the ideologies that led SDL to this point and keep it stuck here.
It does, since the introduction of SDL_ComposeCustomBlendMode() in SDL 2.0.6 (which is necessary to support textures with pre-multiplied alpha). It may be that your searches went back so far that this function had not yet ben added, when it could have reasonably been argued that SDL failed to provide support for this particular issue.
As for why it doesn’t get mentioned much I think that’s only because it’s very rarely of practical significance. I don’t bother to use pre-multiplied alpha because I don’t think I’ve ever seen this effect in practice, but if I do I know how to fix it in SDL2.
I do not understand why you think it should be the responsibility of SDL to “confront” this issue. The described behavior is fundamental to how all the graphics backends work when scaling textures with non-opaque pixels, SDL is simply a wrapper (‘abstraction layer’) to provide a consistent cross-platform interface. So long as SDL exposes the means to workaround it, its job is done.
( Hi! A newbie here, I hope there is no problem if I answer a 7 year old thread! )
I thought those antialiasing issues were natural and to be expected, but found out that they only appeared when I exported to PNG my art from Clip Studio Paint or Adobe Photoshop.
The reason: The transparent pixels cointain color data.
- Photoshop: RGBA(255,255,255,0)
- Clip Studio: RGBA(n,n,n,0) (where n corresponds the surrounding pixels)
Exporting the graphics with GIMP and unchecking the option “Save color values from transparent pixels” seems to have solved it 
Furthermore, this ImageMagick command does the same thing, so it can be easily automatized:
convert.exe 1.png -fill “rgba(0,0,0,0)” -opaque “rgba(255,255,255,0)” png32:1.png
This does not solve how SDL2 (or libpng, or OpenGL, I am not sure) behaves, I do not have enough knowledge to solve it in the code. But removing the color from the fully-transparent pixels solves this problem for me
Updated: It seems that I am not actually solving it. It helps a bit, but does not solve the issue as some artifacts can still appear over bright backgrounds.
Update2: This option in TexturePacker is solving the issue, but I would rather use an FOSS solution, so people will not require a privative tool to use an open sourced engine
Update3: (Please excuse all the recent notifications.) There is an FOSS solution !
The method is “alpha bleeding”:
