Opened 12 months ago

Last modified 12 months ago

#11075 new enhancement

BACKENDS: Get rid of the hideous and slow stretch200To240 function for surface SDL backend

Reported by: rsn8887 Owned by:
Priority: normal Component: Graphics
Keywords: aspect correction SDL Cc:


SurfaceSdlGraphicsManager is already scaling whenever the various stretch and fit modes are used. I think on most if not all platforms that use it, this employs hardware scaling via SDL.

So if hardware scaling works fine, with the user selected filtering etc., then why is there still this kludge called "stretch200To240", an ugly and slow software scaler that is used to do aspect ratio correction in SurfaceSDLGraphicsManager, see here:

This should be implemented by simply adjusting _activeArea to have the correct aspect ratio.

Change History (2)

comment:1 by rsn8887, 12 months ago

Summary: Get rid of the hideous and slow stretch200To240 for SDL backendsBACKENDS: Get rid of the hideous and slow stretch200To240 function for surface SDL backend

comment:2 by criezy, 12 months ago

Getting rid of the stretch200To240 was on my list of things to do (at least when using SDL2) as part of my work to improve the way aspect ratio correction is handled (see Pull Request #1132). There are several reasons to do it:

  • Letting SDL handle the scaling means that it might indeed be done in hardware and be faster.
  • It would also be able to do it in a single pass at the same time it stretches the window (as is done in the OpenGL graphics manager) instead of doing it in two passes and smearing artefacts of the aspect ratio correction during the stretch.
  • It would allow using correction different from the 6:5 correction that is currently always applied. See the pull request link above as to why we want this.

Sadly the work in that pull request has stalled more than a year ago, before I could get to that point, due to burnout. However in the past few months I have slowly been coming back to my list of pending work, and this specific task is near the top of the list. So there is some hope. But of course anybody else is also welcome to take a stab at this.

Note: See TracTickets for help on using tickets.