I second this notion, and I think if the SDL community is going to
continue to try and straddle the chasm between low-end hardware and
modern hardware, a new approach to a rendering API is needed.
I am not proposing that this rendering API be a part of SDL proper,
but it will need SDL’s support to be able to dynamically evaluate its
own rendering costs.
It could be, but it’s not necessary, as long as programs have a way of
ascertaining the cost of raster image transformations.
As Hardcoder noted: the presence of a cache between the source canvas
and the destination canvas should be dynamic, but I don’t think it
correlates so cleanly between whether or not the transformations are
fast. For instance if a sprite changes its transformation parameters
every time it is drawn, it is more costly to require an intervening
buffer and potentially an extra copy operation.
So basically what one would need is an API that allows one to express
composable graphics primitives starting with explicit raster images
(as opposed to automatic/dynamic cache raster images) through graphics
operations (like transformations or compositions; this is where
automatic/dynamic caches live) and finally to their destination
(another explicit raster image, like the framebuffer.) Then for any
application and platform, you would have to tweak some heuristics to
define an effective trade-off between cache overhead penalty and cache
Again, I’m not saying this needs to be a part of SDL, but I think the
discussion needs to be in this direction so that we can understand
exactly what SDL needs to make available for this sort of system to be
implemented on top of it.
For some graphics back-ends, it would probably be enough just to time
blitting and image manipulation operations, but many just won’t work
that way, so we’re probably better off with SDL exposing information
about acceleration to the application. I would add to that also though
that the user should be able to override this information.On Thu, Feb 25, 2010 at 7:36 AM, hardcoder wrote:
Sam Lantinga wrote:
This has come up several times and each time the real pain is the
software rendering. If someone is willing to step up and provide a
software implementation, I’m open to adding it.
My preference would be something like:
SDL_RenderCopyRotated(SDL_texture *texture, const SDL_Rect *srcrect,
const SDL_Rect * dstrect, int angle);
Whoever would implement the software side of this would probably have
to look at src/video/sdlgenblit.pl and add code to output rotating
versions of all those blitters.
I don’t think this is the right way to go. When using hardware
backend like D3D or OGL rotation (or scaling) may be considered
a part of “blit” operation and is a no-cost thing.
On the other hand for software rendering it is the complete opposite
and should not be encouraged on per-frame (or per-redraw / damaged
rect) basis. That said, scaling and rotation operations should be used
during the “blit” ONLY when using hw renderer. When using software
mode, we are back to surfaces and all costly operations like scaling
or rotation should be done at most once per many blits and ideally
only once at load time.
Therefore I propose adding a field to SDL_RendererInfo structure to
query renderer scaling/rotation capabilities.