Proposal: Drop support for software rendering in 1.3

SDL Development
41

Hi,

Currently those layers are SDL_gfx, SDL_image, SDL_mixer, SDL_ttf, etc.

cheers,On Fri, Jan 21, 2011 at 1:37 PM, Ulrich von Zadow wrote:

In general, I think there is a place for a well-thought-out 2D rendering API.

We won’t be using it, though - we’re firmly in camp 2 (’ just want an OpenGL context, and use OpenGL or OpenGL ES to do the job’).

Would it make sense to split the rendering API into a layer above libSDL? That way, only those people who need the functionality need to pull it in.

Cheers,

?Uli

On Jan 21, 2011, at 10:34 AM, Sam Lantinga wrote:

I’m curious, would people rather see the rendering API go away?

Does it increase the complexity of the API without bringing enough functionality to be useful?

–
Any technology distinguishable from magic is insufficiently advanced.

Ulrich von Zadow | +49-172-7872715
Jabber: coder at c-base.org
Skype: uzadow

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

42

From the discussion, I think this is the best option - you can agree or
disagree:

SDL 1.2 is still alive for the many programs that use it to run. It’s not
going anywhere. If SDL 1.3 branches off and breaks compatibility, many
linux distributions will still host SDL 1.2 on their repositories, and I’m
sure Sam can leave it on mercurial and people can submit patches if there
are any issue they encounter.

As far as the SDL_surface API goes, it should just be for creating and free
surfaces. The programmer will have to make their own blitting and drawing
routines. This will minimize the footprint that the software renderer
leaves, and the extra work needed to maintain it in the main branch. We
already have SDL_gfx, and the current source for blitting from the 1.2
respository - wouldn’t be hard to merge blitting with SDL_gfx.

Thoughts?
-AlexOn Fri, Jan 21, 2011 at 8:55 AM, Ren? Dudfield wrote:

Hi,

Currently those layers are SDL_gfx, SDL_image, SDL_mixer, SDL_ttf, etc.

cheers,

On Fri, Jan 21, 2011 at 1:37 PM, Ulrich von Zadow wrote:

In general, I think there is a place for a well-thought-out 2D rendering
API.

We won’t be using it, though - we’re firmly in camp 2 (’ just want an
OpenGL context, and use OpenGL or OpenGL ES to do the job’).

Would it make sense to split the rendering API into a layer above libSDL?
That way, only those people who need the functionality need to pull it in.

Cheers,

Uli

On Jan 21, 2011, at 10:34 AM, Sam Lantinga wrote:

I’m curious, would people rather see the rendering API go away?

Does it increase the complexity of the API without bringing enough
functionality to be useful?

–
Any technology distinguishable from magic is insufficiently advanced.

Ulrich von Zadow | +49-172-7872715
Jabber: coder at c-base.org
Skype: uzadow

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

43

From the discussion, I think this is the best option - you can agree or
disagree:

SDL 1.2 is still alive for the many programs that use it to run. It’s not
going anywhere. If SDL 1.3 branches off and breaks compatibility, many
linux distributions will still host SDL 1.2 on their repositories, and I’m
sure Sam can leave it on mercurial and people can submit patches if there
are any issue they encounter.

As far as the SDL_surface API goes, it should just be for creating and free
surfaces. The programmer will have to make their own blitting and drawing
routines. This will minimize the footprint that the software renderer
leaves, and the extra work needed to maintain it in the main branch. We
already have SDL_gfx, and the current source for blitting from the 1.2
respository - wouldn’t be hard to merge blitting with SDL_gfx.

Thoughts?
-AlexOn Fri, Jan 21, 2011 at 8:55 AM, Ren? Dudfield wrote:

Hi,

Currently those layers are SDL_gfx, SDL_image, SDL_mixer, SDL_ttf, etc.

cheers,

On Fri, Jan 21, 2011 at 1:37 PM, Ulrich von Zadow wrote:

In general, I think there is a place for a well-thought-out 2D rendering
API.

We won’t be using it, though - we’re firmly in camp 2 (’ just want an
OpenGL context, and use OpenGL or OpenGL ES to do the job’).

Would it make sense to split the rendering API into a layer above libSDL?
That way, only those people who need the functionality need to pull it in.

Cheers,

Uli

On Jan 21, 2011, at 10:34 AM, Sam Lantinga wrote:

I’m curious, would people rather see the rendering API go away?

Does it increase the complexity of the API without bringing enough
functionality to be useful?

–
Any technology distinguishable from magic is insufficiently advanced.

Ulrich von Zadow | +49-172-7872715
Jabber: coder at c-base.org
Skype: uzadow

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

44

I think Sam is on the right track. We need to look at what features are
necessary for a simple 2D graphics lib and implement those with HW
acceleration. The issue, though, is whether or not we can make it possible
to extend with fanciness. How could one rotate a SDL_Texture without SDL
doing it and without getting renderer-specific? Could I write a
line-drawing function for textures which performs as well as a built-in SDL
one? Can I use a pixel shader without SDL knowing?

Jonny D

45

After reading I’ve come to a conclusion that should make everyone happy.

Just add these features, even if they’re slow on the software renderer.

The people who use the software renderer now won’t use these features, anyway.
The software renderer will make it easy to see “how it should look” if you’re implementing your own rendering backend.
It can be useful (and maybe optimized – if each software rendering operation had a surface-level implementation too, a programmer can intelligently craft a method to use the features so that it doesn’t kill performance).

That’s what it seems from what I’ve read.------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

46

And I’ve gotta agree with Rene’s "Do we still have buggy drivers?"
bit.

Anybody here who maintains a 3D game can tell you, of course we do. The
buggy drivers didn’t go anywhere. Maybe there are newer versions that
aren’t buggy, but that doesn’t mean people have them.

People who mention this tend to mention it in conjunction with Linux.
Most Linux distributions have good drivers worked out, and for those
that don’t, I really find it difficult to sympathize, especially seeing
as how desktop Linux still maintains less than 1% of market share.

If the Linux community, which is frequently regarded as being quite
above-average when it comes to tech-savviness, can’t get their
collective rear in gear and produce decent OpenGL drivers after it’s
been a standard, expected feature for MORE THAN TEN YEARS NOW, why is
that the 99+% of the rest of our problem?

Without a Linux port, we (Aleph One) would have missed out on many
contributions from Linux developers. The Linux port and SDL are what led
to the Windows port. End users are important, but they are not the only
important component of free software.

To base implementation decisions on problems that a small fraction of a
tiny fraction of potential users might maybe have is a textbook case of
the tail wagging the dog, and it’s kind of embarrassing to see people
talking that way TBH.

I frequently think your replies would benefit from an attempt to see
things from a point of view other than your own. This one irritated me
enough to respond.

Accessibility is one of the characteristics of the free software culture.
Free software is often a refuge for those with unique problems. The fact
that that ideal should color a discussion of SDL’s future isn’t
embarrassing in the least.

GregoryOn Fri, 21 Jan 2011, Mason Wheeler wrote:

47

If we happen to keep software rendering around, maybe some more effort could
be spent using processor
vector extensions to accelerate it more then.

Please excuse me if this is already being done, it is been a while since I
look into SDL source code.–
Paulo

On Fri, Jan 21, 2011 at 3:50 PM, Nathaniel J Fries wrote:

After reading I’ve come to a conclusion that should make everyone happy.

Just add these features, even if they’re slow on the software renderer.

The people who use the software renderer now won’t use these features,
anyway.
The software renderer will make it easy to see “how it should look” if
you’re implementing your own rendering backend.
It can be useful (and maybe optimized – if each software rendering
operation had a surface-level implementation too, a programmer can
intelligently craft a method to use the features so that it doesn’t kill
performance).

That’s what it seems from what I’ve read.

EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

48

Damian Paz wrote:

To be honest I’ve never thought about using SDL to write a game for a 386 SXL.

I see someone has a problem with reading comprehension. It’s as if you haven’t done anything more than skimming the message you replied to. This kind of ignorance is infuriating.

49

If anyone is still doubting that Linux has crappy graphics drivers, I invite them to read this Slashdot thread (http://news.slashdot.org/story/11/01/16/0657240/Why-Linux-Loses-Out-On-Hardware-Acceleration-In-Firefox) (and maybe the article). In short:
nVidia’s closed-source drivers rock

ATI's open-source drivers suck

developers that have expertise with 3D graphics drivers are few so most 3D graphics drivers for Linux are buggy and not well maintained
50

Ahhh…
I wanted a clear answer but how i see Sam doesnt know it too.

51

Hi,

Yes, SDL uses vector SIMD instructions for a few platforms already.

There are not multi core blitters in SDL core. There are some that
have been written for SDL in separate libraries though. Multi core
vector operations can speed things up towards memory bandwidth.
Things like MKL support transparent multi core operation - and are
often used in scientific computing. SDL on a modern desktop
machine(2008+) can easily do video 1920x1080x32bit at 60fps in
software with plenty of cpu left over.

cu,On Fri, Jan 21, 2011 at 3:24 PM, Paulo Pinto wrote:

If we happen to keep software rendering around, maybe some more effort could
be spent using processor
vector extensions to accelerate it more then.

Please excuse me if this is already being done, it is been a while since I
look into SDL source code.

–
Paulo

On Fri, Jan 21, 2011 at 3:50 PM, Nathaniel J Fries wrote:

After reading I’ve come to a conclusion that should make everyone happy.

Just add these features, even if they’re slow on the software renderer.

The people who use the software renderer now won’t use these features,
anyway.
The software renderer will make it easy to see “how it should look” if
you’re implementing your own rendering backend.
It can be useful (and maybe optimized – if each software rendering
operation had a surface-level implementation too, a programmer can
intelligently craft a method to use the features so that it doesn’t kill
performance).

That’s what it seems from what I’ve read.

EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

52

I don’t know about MKL or its portability, but OpenMP is pretty easy to
integrate on its own anyhow.

Jonny DOn Fri, Jan 21, 2011 at 1:01 PM, Ren? Dudfield wrote:

Hi,

Yes, SDL uses vector SIMD instructions for a few platforms already.

There are not multi core blitters in SDL core. There are some that
have been written for SDL in separate libraries though. Multi core
vector operations can speed things up towards memory bandwidth.
Things like MKL support transparent multi core operation - and are
often used in scientific computing. SDL on a modern desktop
machine(2008+) can easily do video 1920x1080x32bit at 60fps in
software with plenty of cpu left over.

cu,

On Fri, Jan 21, 2011 at 3:24 PM, Paulo Pinto wrote:

If we happen to keep software rendering around, maybe some more effort
could
be spent using processor
vector extensions to accelerate it more then.

Please excuse me if this is already being done, it is been a while since
I
look into SDL source code.

–
Paulo

On Fri, Jan 21, 2011 at 3:50 PM, Nathaniel J Fries wrote:

After reading I’ve come to a conclusion that should make everyone happy.

Just add these features, even if they’re slow on the software renderer.

The people who use the software renderer now won’t use these features,
anyway.
The software renderer will make it easy to see “how it should look” if
you’re implementing your own rendering backend.
It can be useful (and maybe optimized – if each software rendering
operation had a surface-level implementation too, a programmer can
intelligently craft a method to use the features so that it doesn’t kill
performance).

That’s what it seems from what I’ve read.

EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

53

On, Fri Jan 21, 2011, Rene Dudfield wrote:

Hi,

Yes, SDL uses vector SIMD instructions for a few platforms already.

There are not multi core blitters in SDL core. There are some that
have been written for SDL in separate libraries though. Multi core
vector operations can speed things up towards memory bandwidth.
Things like MKL support transparent multi core operation - and are
often used in scientific computing. SDL on a modern desktop
machine(2008+) can easily do video 1920x1080x32bit at 60fps in
software with plenty of cpu left over.

On a side note we also have made a good experience with using
multiprocessing and multiprocessor extensions for software rendering
(blits, pixel copies, blending) within pygame (using OpenMP).

Best
Marcus
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20110121/88f29537/attachment.pgp

54

There is never going to be a general consensus as to which features are
necessary for a 2D rendering API. You can keep adding features, all of
them useful features that somebody need, and soon you’ve exposed the
whole OpenGL API.

I’m strongly in favor of keeping the rendering API minimal, and writing
more sophisticated rendering APIs as a separate layer on top of SDL.
SDL’s main purpose is to act as a cross-platform compatibility layer.
Let’s not confuse this purpose by adding features that could easily be
implemented in a platform-independent manner on top of SDL.On 1/21/2011 03:53, Jcw87 wrote:

I think that it is important to add some newer features, such as
clipping and render-to-texture. I had to start learning OpenGL
because these things were missing from the render API. At the same
time, it is also important to have a fallback renderer, in case a
hardware accelerated renderer could not be created for whatever
reason. I think it would be best to keep the software renderer,
adding new features to it as needed, even if they turn out to be
really slow.

–
Rainer Deyke - rainerd at eldwood.com

55

I’m strongly in favor of keeping the rendering API minimal, and writing
more sophisticated rendering APIs as a separate layer on top of SDL.
SDL’s main purpose is to act as a cross-platform compatibility layer.
Let’s not confuse this purpose by adding features that could easily be
implemented in a platform-independent manner on top of SDL.

Sure, except there’s one little problem with that: it won’t work, at least
not the way SDL 1.3 is currently architected. SDL_Textures are opaque
pointers to platform-independent structs containing opaque pointers
to platform-specific structs. That’s two missing levels of indirection away
from the data you would need to implement any new image manipulation
or rendering features externally.>----- Original Message ----

From: Rainer Deyke
Subject: Re: [SDL] Proposal: Drop support for software rendering in 1.3

56

They could be exposed… Then these features could be lifted to an
additional library instead of bothering everyone who feels affected.

Jonny DOn Fri, Jan 21, 2011 at 4:13 PM, Mason Wheeler wrote:

----- Original Message ----

From: Rainer Deyke
Subject: Re: [SDL] Proposal: Drop support for software rendering in 1.3

I’m strongly in favor of keeping the rendering API minimal, and writing
more sophisticated rendering APIs as a separate layer on top of SDL.
SDL’s main purpose is to act as a cross-platform compatibility layer.
Let’s not confuse this purpose by adding features that could easily be
implemented in a platform-independent manner on top of SDL.

Sure, except there’s one little problem with that: it won’t work, at least
not the way SDL 1.3 is currently architected. SDL_Textures are opaque
pointers to platform-independent structs containing opaque pointers
to platform-specific structs. That’s two missing levels of indirection
away
from the data you would need to implement any new image manipulation
or rendering features externally.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

57

Mason Wheeler wrote:

I’m strongly in favor of keeping the rendering API minimal, and writing
more sophisticated rendering APIs as a separate layer on top of SDL.
SDL’s main purpose is to act as a cross-platform compatibility layer.
Let’s not confuse this purpose by adding features that could easily be
implemented in a platform-independent manner on top of SDL.

Sure, except there’s one little problem with that: it won’t work, at least
not the way SDL 1.3 is currently architected. SDL_Textures are opaque
pointers to platform-independent structs containing opaque pointers
to platform-specific structs. That’s two missing levels of indirection away
from the data you would need to implement any new image manipulation
or rendering features externally.

I am in agreement here. If they were to be moved to a separate library, SDL as it is would need to be restructured to expose these things; and then there’d probably still be a ton of code duplication and such in the new library anyway. It makes sense to put it into SDL if it’s something like this; even if it won’t be used by everyone who uses SDL. The library could be reliably modularized much easier than opaque structures can be readily exposed and reliably modified in a cross-platform manner.> > ----- Original Message ----

From: Rainer Deyke
Subject: Re: [SDL] Proposal: Drop support for software rendering in 1.3

EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

58

The renderer would of course be implemented on top of OpenGL (or the
frame buffer interface for software rendering), not on top of SDL’s 2D
rendering API.

The situation you’re describing is exactly why it’s a bad idea to add
too many features to SDL’s 2D rendering API. SDL’s 2D rendering API is
not extensible. Therefore, if you’re doing any sophisticated rendering,
you will eventually be forced to drop the 2D rendering API and switch to
OpenGL. Adding features to SDL’s 2D rendering API can only delay this
transition, thereby making the transition all the more painful.

The only API that exposes the full power of OpenGL is OpenGL itself.On 1/21/2011 14:13, Mason Wheeler wrote:

Sure, except there’s one little problem with that: it won’t work, at least
not the way SDL 1.3 is currently architected. SDL_Textures are opaque
pointers to platform-independent structs containing opaque pointers
to platform-specific structs. That’s two missing levels of indirection away
from the data you would need to implement any new image manipulation
or rendering features externally.

–
Rainer Deyke - rainerd at eldwood.com

59

Neil White wrote:

i t
but, saying that, the ‘just use sdl1.2’ is the best and sdl1.3 should move to reflect modern technologies rather than keep a minority of users and developers happy,

perhaps even make a sure of distinguishing the difference between sdl1.2 and sdl1.3 by upon release calling it something else, like sdml or something, that would also mean less headache when having both new sdl and old sdl on the same system ( esp linux )

I will make this short and sweet because I think this is a bad suggestion.

  1. We do advanced video processing on mobile devices and set-top boxes. (Do you really call that legacy)

  2. We use yuv12 rendering , many of these platfroms use open gl es 1.0 which does not support yuv12, sdl is meant to be a cross platform compatibility layer sometimes that is true others times it falls short of that , however it is very good at bridging the gap between legacy pre open gl linux platforms, newer windows and mac platforms and iphones , android and set-top boxes. We use it to great extent in those later areas.

  3. aside from the yuv12 rendering capabilities we utilize many advanced open gl capabilities. For those of you who have attempted to use rotozoom on the iphone platform you know that it pails in comparison to open gl code.

  4. SDL 1.2 DOES NOT meet our needs

I strongly vote no on any such proposal.

60

Why dont make a extra lib for the Hardwareaccelerated Stuff? -> Everyone is happy.

Thos Guys who wnat that just add the lib those who dont just use only SDL