SFML 2.0 vs SDL 1.3

Both are undergoing development
Both support hardware accelerated 2D out of the box
Both are licensed under the zlib license -- that's right, you are now free to statically link SDL to your programs

SFML is mostly supported by one developer, a much smaller team than the one behind SDL
SFML is only aimed at Windows/Linux/OSX for the moment, while SDL supports a much wider range of platforms
SFML 2.0 is pretty unstable at the moment, with the lead developer stating that he's prepared to completely break parts of the API prior to the 2.0 release
SDL 1.3 is probably pretty unstable as well
SFML has a much more friendly API than SDL, in my experience, although this is limited to usage of 1.2

Given my limited knowledge of SDL 1.3, I'm not sure which is the better library to side with. I originally jumped ship from SDL to SFML because of its friendlier API and hardware accelerated 2D graphics, but if SDL 1.3 is going to feature similar hardware acceleration along with a brisker, more reliable pace of development, my inclined to side with it. Can /prog/ convince me to pick a camp?

>>10
it just indicates there is alot of code for very little function.
So what? Maybe it's infinitely decompressed or something, anyway, why do you care about functionality density per megabyte? Why is this a metric that one should strive to optimize?

I feel like you maybe read too many books which brainwashed you with patriarchal preconceptions.

>>12
Its simply called bloat.
And why you say that as if it were something bad?
I don't read books,
Then you got yourself brainwashed by something else.
i just see this library advertised as "fast and efficient".
What's slow and inefficient about it?

>>13
well, that's kind of my point. You see people trying to create something under some artificial constraints. You can call it "art" or "intellectual masturbation", or whatever, that's OK, no problemo.

But if you forget about the fact that the constraints are artificial, then you get brainwashed by the semi-imaginary peer pressure which tells you that no "bloat" is good, because it's good, because look at how respected fr are, you should respect what respected people do and try to be respected as well, so stay away from the bloat! First rule of the no-bloat club: don't question why bloat is bad!

I don't have to prove that bloat is bad, it obvious
Heh.

that functionality which comes at lesser cost is better than one that comes at higher cost.
Define cost.

You can fiddle with gigabyte sapping, memory leaking VMs and gigantic libraries all day, that typical for AAA-class Enterprise Software Developers
Here we can see how brainwashed individual tries to further assert his ad hominem and the notion that the questioner belongs to a hostile class, which is why his questions are dangerous to even try to answer.

its just not as efficient
You must say that it is not as efficient three times, only then it will become true. Two times are not enough.

or elegant in terms of design as
Oh, yes, sure, it's not "elegant", it's not "beautiful", it's not a piece of art -- not something created under pointless constraints.

By the way, while we are at it, do you realize that we are discussing the size of the binary, not the source code? Not that it is terribly important, since your rinsed and dried brain blows fuses when it detects questioning of your silly beliefs either way.