SDL 2.0.1 + opengl render driver + SDL2_gfx = slow

Dark_Oppressor · November 3, 2013, 9:29am

On Windows, my program was using SDL 2.0.0 and SDL2_gfx r5. I use the opengl render driver by calling ‘SDL_SetHint(SDL_HINT_RENDER_DRIVER,“opengl”);’. Everything was working perfectly until:

I just upgraded to SDL 2.0.1 and SDL2_gfx 1.0.0. Now, whenever I’m calling SDL2_gfx render functions (thickLineRGBA to be exact, ~32 times per frame) performance slows to a crawl. I tried reverting to SDL2_gfx r5 but that didn’t change anything. Changing the render driver to direct3d does solve the problem.

I just built the 32 and 64-bit Linux versions of my program, and they both have the same problem. Obviously, I can’t change the render driver to direct3d there, so I can’t really test anything else. But the opengl render driver seems to hate SDL2_gfx now. Does this sound like a bug I should report, or is there maybe some new change I am unaware of that could cause this?

Dark_Oppressor · November 3, 2013, 10:15am

OK, I tested SDL2_gfx’s filledCircleRGBA and circleRGBA functions, and they cause the same slowdown. I also compiled the OS X version of my program and it also has the same problem with the opengl render driver.

Andreas_Schiffler · November 3, 2013, 4:31pm

SDL2_gfx functions put graphics on the screen via a stack of
SDL_RenderDrawPoint and SDL_RenderDrawLine calls, i.e. internally these
are called repeatedly: return SDL_RenderDrawLine(renderer, x1, y1, x2, y2);
return SDL_RenderDrawPoint(renderer, x, y);

As far as I can tell, there are no recent changes in SDL_render.c
(http://hg.libsdl.org/SDL/log/cc2289c332eb/src/render/SDL_render.c) that
should affect Linux.
There was one change affecting the OSX code path for some settings
(http://hg.libsdl.org/SDL/rev/6a05d7352575) a few weeks back.

I’ll update the SDL2_gfx testgfx program now to add back some of the
benchmarking code from SDL_gfx so one can do some comparisons of the
performance on different architectures.

Cheers,
–AndreasOn 11/3/2013 2:15 AM, Dark_Oppressor wrote:

OK, I tested SDL2_gfx’s filledCircleRGBA and circleRGBA functions, and
they cause the same slowdown. I also compiled the OS X version of my
program and it also has the same problem with the opengl render driver.

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

Andreas_Schiffler · November 3, 2013, 6:16pm

I’ve updated the SDL2_gfx testgfx program to calculate some benchmark
numbers and print them to the console [r11].
On my windows box, the opengl renderer is about twice as fast as the
directx renderer.

cygwin 32bit

INFO: SDL2_gfx 1.0.0: testgfx
INFO: Platform: Windows
INFO: Renderer 0: direct3d (Accelerated)
INFO: Pixel: 341333.3 /sec
INFO: Hline: 85333.3 /sec
INFO: Vline: 102400.0 /sec
INFO: Rectangle: 146285.7 /sec
INFO: RoundedRectangle: 10666.7 /sec
INFO: Box: 170666.7 /sec
INFO: Line: 93090.9 /sec
INFO: Circle: 4339.0 /sec
INFO: AACircle: 2039.8 /sec
INFO: FilledCircle: 3150.8 /sec
INFO: Ellipse: 3413.3 /sec
INFO: AAEllipse: 1910.4 /sec
INFO: FilledEllipse: 3103.0 /sec
INFO: Bezier: 312.2 /sec
INFO: Polygon: 113666.7 /sec
INFO: AAPolygon: 675.5 /sec
INFO: FilledPolygon: 1024.0 /sec
INFO: Trigon: 256000.0 /sec
INFO: Arc: 9102.2 /sec
INFO: Pie: 113777.8 /sec
INFO: FilledPie: 4145.7 /sec
INFO: ThickLine: 350.5 /sec

INFO: SDL2_gfx 1.0.0: testgfx
INFO: Platform: Windows
INFO: Renderer 0: opengl (Accelerated)
INFO: Pixel: 512000.0 /sec
INFO: Hline: 341333.3 /sec
INFO: Vline: 341333.3 /sec
INFO: Rectangle: 341333.3 /sec
INFO: RoundedRectangle: 26256.4 /sec
INFO: Box: 341333.3 /sec
INFO: Line: 341333.3 /sec
INFO: Circle: 8752.1 /sec
INFO: AACircle: 3969.0 /sec
INFO: FilledCircle: 12962.0 /sec
INFO: Ellipse: 7013.7 /sec
INFO: AAEllipse: 3806.7 /sec
INFO: FilledEllipse: 12962.0 /sec
INFO: Bezier: 1258.5 /sec
INFO: Polygon: 341000.0 /sec
INFO: AAPolygon: 1306.1 /sec
INFO: FilledPolygon: 4339.0 /sec
INFO: Trigon: 341333.3 /sec
INFO: Arc: 18450.5 /sec
INFO: Pie: 186181.8 /sec
INFO: FilledPie: 16126.0 /sec
INFO: ThickLine: 700.2 /sec

VS2012Release

INFO: Platform: Windows
INFO: Renderer 0: direct3d (Accelerated)
INFO: Pixel: 341333.3 /sec
INFO: Hline: 146285.7 /sec
INFO: Vline: 128000.0 /sec
INFO: Rectangle: 204800.0 /sec
INFO: RoundedRectangle: 10138.6 /sec
INFO: Box: 204800.0 /sec
INFO: Line: 146285.7 /sec
INFO: Circle: 3938.4 /sec
INFO: AACircle: 1903.3 /sec
INFO: FilledCircle: 2745.3 /sec
INFO: Ellipse: 3605.6 /sec
INFO: AAEllipse: 1855.0 /sec
INFO: FilledEllipse: 3056.7 /sec
INFO: Bezier: 312.6 /sec
INFO: Polygon: 170500.0 /sec
INFO: AAPolygon: 664.9 /sec
INFO: FilledPolygon: 922.5 /sec
INFO: Trigon: 256000.0 /sec
INFO: Arc: 9266.9 /sec
INFO: Pie: 136533.3 /sec
INFO: FilledPie: 4015.6 /sec
INFO: ThickLine: 283.9 /sec

INFO: Platform: Windows
INFO: Renderer 0: opengl (Accelerated)
INFO: Pixel: 682666.6 /sec
INFO: Hline: 341333.3 /sec
INFO: Vline: 341333.3 /sec
INFO: Rectangle: 512000.0 /sec
INFO: RoundedRectangle: 33032.2 /sec
INFO: Line: 341333.3 /sec
INFO: Circle: 11252.7 /sec
INFO: AACircle: 4876.1 /sec
INFO: FilledCircle: 13837.8 /sec
INFO: Ellipse: 9570.0 /sec
INFO: AAEllipse: 5044.3 /sec
INFO: FilledEllipse: 15515.1 /sec
INFO: Bezier: 1460.7 /sec
INFO: Polygon: 341000.0 /sec
INFO: AAPolygon: 1759.4 /sec
INFO: FilledPolygon: 4491.2 /sec
INFO: Trigon: 409600.0 /sec
INFO: Arc: 23813.9 /sec
INFO: Pie: 292571.4 /sec
INFO: FilledPie: 17355.9 /sec
INFO: ThickLine: 782.1 /secOn 11/3/2013 8:31 AM, Andreas Schiffler wrote:

SDL2_gfx functions put graphics on the screen via a stack of
SDL_RenderDrawPoint and SDL_RenderDrawLine calls, i.e. internally
these are called repeatedly: return SDL_RenderDrawLine(renderer, x1,
y1, x2, y2);
return SDL_RenderDrawPoint(renderer, x, y);
As far as I can tell, there are no recent changes in SDL_render.c
(http://hg.libsdl.org/SDL/log/cc2289c332eb/src/render/SDL_render.c)
that should affect Linux.
There was one change affecting the OSX code path for some settings
(http://hg.libsdl.org/SDL/rev/6a05d7352575) a few weeks back.

I’ll update the SDL2_gfx testgfx program now to add back some of the
benchmarking code from SDL_gfx so one can do some comparisons of the
performance on different architectures.

Cheers,
–Andreas

On 11/3/2013 2:15 AM, Dark_Oppressor wrote:

OK, I tested SDL2_gfx’s filledCircleRGBA and circleRGBA functions,
and they cause the same slowdown. I also compiled the OS X version of
my program and it also has the same problem with the opengl render
driver.

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

Dark_Oppressor · November 4, 2013, 2:01am

OK, I compiled r11 and here are my testgfx results:

VS2012 Release

INFO: SDL2_gfx 1.0.0: testgfx
INFO: Platform: Windows
INFO: Renderer 0: direct3d (Accelerated)
INFO: Pixel: 2048000.0 /sec
INFO: Hline: 1024000.0 /sec
INFO: Vline: 1024000.0 /sec
INFO: Rectangle: 1024000.0 /sec
INFO: RoundedRectangle: 26256.4 /sec
INFO: Box: 341333.3 /sec
INFO: Line: 1024000.0 /sec
INFO: Circle: 7876.9 /sec
INFO: AACircle: 3379.5 /sec
INFO: Ellipse: 6282.2 /sec
INFO: AAEllipse: 3401.9 /sec
INFO: FilledEllipse: 10893.6 /sec
INFO: Bezier: 900.8 /sec
INFO: AAPolygon: 1224.8 /sec
INFO: FilledPolygon: 2844.4 /sec
INFO: Trigon: 409600.0 /sec
INFO: Arc: 16384.0 /sec
INFO: Pie: 97523.8 /sec
INFO: FilledPie: 10448.9 /sec
INFO: ThickLine: 523.8 /sec
INFO: TexturedPolygon: 1656.9 /sec

INFO: SDL2_gfx 1.0.0: testgfx
INFO: Platform: Windows
INFO: Renderer 0: opengl (Accelerated)
INFO: Pixel: 682666.6 /sec
INFO: Hline: 341333.3 /sec
INFO: Vline: 512000.0 /sec
INFO: Rectangle: 512000.0 /sec
INFO: RoundedRectangle: 34133.3 /sec
INFO: Box: 1024000.0 /sec
INFO: Line: 341333.3 /sec
INFO: Circle: 12047.0 /sec
INFO: AACircle: 4376.0 /sec
INFO: FilledCircle: 18285.7 /sec
INFO: Ellipse: 10138.6 /sec
INFO: AAEllipse: 4320.6 /sec
INFO: FilledEllipse: 18618.1 /sec
INFO: Bezier: 1363.3 /sec
INFO: Polygon: 341000.0 /sec
INFO: AAPolygon: 1242.7 /sec
INFO: FilledPolygon: 5389.4 /sec
INFO: Trigon: 341333.3 /sec
INFO: Arc: 24674.6 /sec
INFO: Pie: 128000.0 /sec
INFO: FilledPie: 17655.1 /sec
INFO: ThickLine: 861.1 /sec
INFO: TexturedPolygon: 1798.0 /sec

I also threw together a benchmark within my engine. I set it to render nothing except as many lines as it can in a second 10 times and then averaged the results, and got this:

direct3d:
thickLineRGBA (width of 1) Lines drawn: 3482.6 /sec
SDL_RenderDrawLine Lines drawn: 263305 /sec

opengl:
thickLineRGBA (width of 1) Lines drawn: 5048.9 /sec
SDL_RenderDrawLine Lines drawn: 396922 /sec

Then I did an FPS comparison (sitting on the main menu).
For each render driver and function I tested with just the main menu, and with the console on. The console is two empty rectangles (so total of 8 line render calls) and two full rectangles, drawn with SDL_RenderFillRect. For the calls to thickLineRGBA, I used a width of 1.

direct3d:
thickLineRGBA:
console off: 60
console on: 30

SDL_RenderDrawLine:
console off: 300
console on: 287

opengl:
thickLineRGBA:
console off: 70
console on: 37

SDL_RenderDrawLine:
console off: 201
console on: 197

Conclusions:
OpenGL seems to be faster than Direct3D in most cases. It looks like my thinking from the first post that the problem was related to OpenGL was wrong.

I did find that SDL_RenderDrawLine is considerably faster than thickLineRGBA in all of my tests, all other things being equal. That shouldn’t be the case, should it? I also did some less formal tests where I didn’t force line width to 1 for all calls to thickLineRGBA. Predictably, it became much slower than SDL_RenderDrawLine when I did that.

Of related note is what happened when I added just a few more line renders. For SDL_RenderDrawLine, this caused a very tiny drop in FPS. However, thickLineRGBA rapidly slowed to a crawl with those same added line renders. This was all true across render drivers, and remember this is with identical lines being drawn and all of width 1 when using thickLineRGBA.

Doesn’t this seem weird?

Dark_Oppressor · November 4, 2013, 2:17am

For comparison I just went and reran the FPS test under just OpenGL with SDL 2.0.0 instead. I’m still using a line width of 1. Here is what I saw:

opengl:
thickLineRGBA:
console off: 186
console on: 110

SDL_RenderDrawLine:
console off: 257
console on: 247

This matches up with the difference between SDL 2.0.0 and 2.0.1 that originally brought me here. There is a very real difference in performance.

Andreas_Schiffler · November 4, 2013, 5:32am

Not really

thickLineRGBA is slow; the algorithm is a port from a PostScript
renderer - it is functional & graphically correct, but not very optimized
thickLineRGBA with a width of 1 should be special-cased to use the
regular line algorithm - I’ll fix that in the next SDL2_gfx releaseOn 11/3/2013 6:01 PM, Dark_Oppressor wrote:

I did find that SDL_RenderDrawLine is considerably faster than
thickLineRGBA in all of my tests, all other things being equal. That
shouldn’t be the case, should it? I also did some less formal tests
where I didn’t force line width to 1 for all calls to thickLineRGBA.
Predictably, it became much slower than SDL_RenderDrawLine when I did
that.

Of related note is what happened when I added just a few more line
renders. For SDL_RenderDrawLine, this caused a very tiny drop in FPS.
However, thickLineRGBA rapidly slowed to a crawl with those same added
line renders. This was all true across render drivers, and remember
this is with identical lines being drawn and all of width 1 when using
thickLineRGBA.

Doesn’t this seem weird?

Dark_Oppressor · November 4, 2013, 10:42am

Andreas Schiffler wrote:

Not really

thickLineRGBA is slow; the algorithm is a port from a PostScript
renderer - it is functional & graphically correct, but not very optimized

thickLineRGBA with a width of 1 should be special-cased to use the
regular line algorithm - I’ll fix that in the next SDL2_gfx release

Cool, thanks

At this point, I’m seeing a pretty big performance drop in both thickLineRGBA and SDL_RenderDrawLine when moving from SDL 2.0.0 to 2.0.1. This was the case on Windows, OS X, and Linux. Does this sound bug-like? Something has definitely changed, and I don’t see how it could be on my end. All I changed was one library, and the problem is on a variety of OSs, architectures, and physical machines.

Andreas_Schiffler · November 4, 2013, 4:17pm

Yup - that sounds like a regression.
Could you open a bug on https://bugzilla.libsdl.org with repro steps
(either some test source code and/or steps using SDL2_gfx) and your
measurements numbers that show the difference.On 11/4/2013 2:42 AM, Dark_Oppressor wrote:

Andreas Schiffler wrote:

Not really Smile

thickLineRGBA is slow; the algorithm is a port from a PostScript
renderer - it is functional & graphically correct, but not very optimized

thickLineRGBA with a width of 1 should be special-cased to use the
regular line algorithm - I’ll fix that in the next SDL2_gfx release

Cool, thanks Smile

At this point, I’m seeing a pretty big performance drop in both
thickLineRGBA and SDL_RenderDrawLine when moving from SDL 2.0.0 to
2.0.1. This was the case on Windows, OS X, and Linux. Does this sound
bug-like? Something has definitely changed, and I don’t see how it
could be on my end. All I changed was one library, and the problem is
on a variety of OSs, architectures, and physical machines.

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

slouken · November 5, 2013, 4:17am

Offhand, I’m guessing it’s the line change to glDrawArrays() that’s
affecting you.

You should be able to test that hypothesis by backing out these two
changesets:

Does your program draw so many lines that this change causes real-world
performance issues for you?On Mon, Nov 4, 2013 at 8:17 AM, Andreas Schiffler wrote:

Yup - that sounds like a regression.
Could you open a bug on https://bugzilla.libsdl.org with repro steps
(either some test source code and/or steps using SDL2_gfx) and your
measurements numbers that show the difference.

On 11/4/2013 2:42 AM, Dark_Oppressor wrote:

Andreas Schiffler wrote:
Not really [image: Smile]

thickLineRGBA is slow; the algorithm is a port from a PostScript
renderer - it is functional & graphically correct, but not very optimized

thickLineRGBA with a width of 1 should be special-cased to use the
regular line algorithm - I’ll fix that in the next SDL2_gfx release

Cool, thanks [image: Smile]

At this point, I’m seeing a pretty big performance drop in both
thickLineRGBA and SDL_RenderDrawLine when moving from SDL 2.0.0 to 2.0.1.
This was the case on Windows, OS X, and Linux. Does this sound bug-like?
Something has definitely changed, and I don’t see how it could be on my
end. All I changed was one library, and the problem is on a variety of OSs,
architectures, and physical machines.

SDL mailing listSDL at lists.libsdl.orghttp://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

Andreas_Schiffler · November 5, 2013, 4:30pm

You were correct - these two revisions are the cause for the performance
regression.

SDL2_gfx relies on pixel and line rendering to compose the primitives.
All primitives seem to experience a slowdown, sometimes a significant one.

$ ./testgfx.exe --renderer OpenGL
INFO: SDL2_gfx 1.0.0: testgfx
INFO: Platform: Windows
INFO: Renderer 0: opengl (Accelerated)
…

Primitive Orig HG Run1 Orig HG Run2 Orig HG Avg. -2 Rev Run1 -2 Rev
Run2 -2 Rev Avg Speedup with 7840&7842 reverted
Pixel 712,348 744,727 728,538 1,489,455 1,820,444 1,654,949 227%
Hline 390,095 390,095 390,095 431,158 431,158 431,158 111%
Vline 390,095 390,095 390,095 431,158 431,158 431,158 111%
Rectangle 372,364 390,095 381,229 1,638,400 1,638,400 1,638,400 430%
RoundedRectangle 26,771 26,597 26,684 53,195 51,848 52,521 197%
Box 1,024,000 1,170,286 1,097,143 1,365,333 1,638,400 1,501,867 137%
Line 372,364 390,095 381,229 455,111 431,158 443,135 116%
Circle 8,266 8,176 8,221 21,787 21,445 21,616 263%
AACircle 3,846 3,910 3,878 9,846 9,776 9,811 253%
FilledCircle 12,431 6,798 9,615 18,204 17,430 17,817 185%
Ellipse 6,715 6,715 6,715 17,504 17,210 17,357 258%
AAEllipse 3,710 3,720 3,715 9,320 9,153 9,236 249%
FilledEllipse 12,469 12,450 12,459 18,286 17,504 17,895 144%
Bezier 1,212 1,217 1,215 1,836 1,760 1,798 148%
Polygon 364,067 341,313 352,690 1,365,250 1,365,250 1,365,250 387%
AAPolygon 1,212 1,256 1,234 3,165 3,148 3,157 256%
FilledPolygon 4,137 4,146 4,142 6,169 5,769 5,969 144%
Trigon 364,089 356,174 360,131 1,365,333 1,260,308 1,312,821 365%
Arc 17,751 18,044 17,897 46,283 46,283 46,283 259%
Pie 210,051 207,392 208,722 348,596 341,333 344,965 165%
FilledPie 14,655 14,681 14,668 20,845 19,811 20,328 139%
ThickLine 618 616 617 1,648 1,631 1,639 266%

TOTAL	219%On 11/4/2013 8:17 PM, Sam Lantinga wrote:

Offhand, I’m guessing it’s the line change to glDrawArrays() that’s
affecting you.

You should be able to test that hypothesis by backing out these two
changesets:
https://hg.libsdl.org/SDL/rev/a37d23ee1812
https://hg.libsdl.org/SDL/rev/7e9cd472a889

Does your program draw so many lines that this change causes
real-world performance issues for you?

On Mon, Nov 4, 2013 at 8:17 AM, Andreas Schiffler <@Andreas_Schiffler mailto:Andreas_Schiffler> wrote:

Yup - that sounds like a regression.
Could you open a bug on https://bugzilla.libsdl.org with repro
steps (either some test source code and/or steps using SDL2_gfx)
and your measurements numbers that show the difference.


On 11/4/2013 2:42 AM, Dark_Oppressor wrote:

Andreas Schiffler wrote:

Not really Smile
- thickLineRGBA is slow; the algorithm is a port from a PostScript
renderer - it is functional & graphically correct, but not very
optimized
- thickLineRGBA with a width of 1 should be special-cased to use the
regular line algorithm - I'll fix that in the next SDL2_gfx release



Cool, thanks Smile

At this point, I'm seeing a pretty big performance drop in both
thickLineRGBA and SDL_RenderDrawLine when moving from SDL 2.0.0
to 2.0.1. This was the case on Windows, OS X, and Linux. Does
this sound bug-like? Something has definitely changed, and I
don't see how it could be on my end. All I changed was one
library, and the problem is on a variety of OSs, architectures,
and physical machines.


_______________________________________________
SDL mailing list
SDL at lists.libsdl.org  <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list
SDL at lists.libsdl.org <mailto: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

slouken · November 6, 2013, 5:10am

This should be fixed:

T_Joseph_Carter · November 6, 2013, 7:27am

I’m not convinced that SDL2_gfx should be doing the equivalent of
putpixel and drawline directly to accelerated targets. It’s very
"software-rendery" and I know SDL’s 2D renderer is supposed to feel
like you’re working on a software renderer even when you’re not, but
I’d almost rather implement basic outline and filled polygons in the
software renderer and use flat shaded triangle fans in the hardware
renderers.

This isn’t even difficult to do, unless the shape you want to create
in 3D is a circle/ellipse. And then it’s not TOO bad because the
number of triangles needed to create a pixel-perfect “circle” is
actually deterministic if not terribly simple. It lends itself to an
easy implementation using vertex arrays and a simple loop if you’re
running some antique 3Dfx card card or something. (That’s
actually possible under X.org, but do those things even work under
Windows XP?)

JosephOn Tue, Nov 05, 2013 at 08:30:46AM -0800, Andreas Schiffler wrote:

You were correct - these two revisions are the cause for the
performance regression.

SDL2_gfx relies on pixel and line rendering to compose the
primitives. All primitives seem to experience a slowdown, sometimes a
significant one.

$ ./testgfx.exe --renderer OpenGL
INFO: SDL2_gfx 1.0.0: testgfx
INFO: Platform: Windows
INFO: Renderer 0: opengl (Accelerated)
…

Primitive Orig HG Run1 Orig HG Run2 Orig HG Avg. -2 Rev Run1 -2
Rev Run2 -2 Rev Avg Speedup with 7840&7842 reverted
Pixel 712,348 744,727 728,538 1,489,455 1,820,444 1,654,949 227%
Hline 390,095 390,095 390,095 431,158 431,158 431,158 111%
Vline 390,095 390,095 390,095 431,158 431,158 431,158 111%
Rectangle 372,364 390,095 381,229 1,638,400 1,638,400 1,638,400 430%
RoundedRectangle 26,771 26,597 26,684 53,195 51,848 52,521 197%
Box 1,024,000 1,170,286 1,097,143 1,365,333 1,638,400 1,501,867 137%
Line 372,364 390,095 381,229 455,111 431,158 443,135 116%
Circle 8,266 8,176 8,221 21,787 21,445 21,616 263%
AACircle 3,846 3,910 3,878 9,846 9,776 9,811 253%
FilledCircle 12,431 6,798 9,615 18,204 17,430 17,817 185%
Ellipse 6,715 6,715 6,715 17,504 17,210 17,357 258%
AAEllipse 3,710 3,720 3,715 9,320 9,153 9,236 249%
FilledEllipse 12,469 12,450 12,459 18,286 17,504 17,895 144%
Bezier 1,212 1,217 1,215 1,836 1,760 1,798 148%
Polygon 364,067 341,313 352,690 1,365,250 1,365,250 1,365,250 387%
AAPolygon 1,212 1,256 1,234 3,165 3,148 3,157 256%
FilledPolygon 4,137 4,146 4,142 6,169 5,769 5,969 144%
Trigon 364,089 356,174 360,131 1,365,333 1,260,308 1,312,821 365%
Arc 17,751 18,044 17,897 46,283 46,283 46,283 259%
Pie 210,051 207,392 208,722 348,596 341,333 344,965 165%
FilledPie 14,655 14,681 14,668 20,845 19,811 20,328 139%
ThickLine 618 616 617 1,648 1,631 1,639 266%

TOTAL 219%

On 11/4/2013 8:17 PM, Sam Lantinga wrote:

Offhand, I’m guessing it’s the line change to glDrawArrays() that’s
affecting you.

You should be able to test that hypothesis by backing out these two
changesets:
https://hg.libsdl.org/SDL/rev/a37d23ee1812
https://hg.libsdl.org/SDL/rev/7e9cd472a889

Does your program draw so many lines that this change causes
real-world performance issues for you?

On Mon, Nov 4, 2013 at 8:17 AM, Andreas Schiffler <aschiffler at ferzkopp.net <mailto:aschiffler at ferzkopp.net>> wrote:

Yup - that sounds like a regression.
Could you open a bug on https://bugzilla.libsdl.org with repro
steps (either some test source code and/or steps using SDL2_gfx)
and your measurements numbers that show the difference.

On 11/4/2013 2:42 AM, Dark_Oppressor wrote:

Andreas Schiffler wrote:

Not really Smile

thickLineRGBA is slow; the algorithm is a port from a PostScript
renderer - it is functional & graphically correct, but not very
optimized

thickLineRGBA with a width of 1 should be special-cased to use the
regular line algorithm - I’ll fix that in the next SDL2_gfx release

Cool, thanks Smile

At this point, I’m seeing a pretty big performance drop in both
thickLineRGBA and SDL_RenderDrawLine when moving from SDL 2.0.0
to 2.0.1. This was the case on Windows, OS X, and Linux. Does
this sound bug-like? Something has definitely changed, and I
don’t see how it could be on my end. All I changed was one
library, and the problem is on a variety of OSs, architectures,
and physical machines.

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

SDL mailing list
SDL at lists.libsdl.org <mailto: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

Gabriele_Greco · November 6, 2013, 2:00pm

This should be fixed:
https://hg.libsdl.org/SDL/rev/b339af982b62

I’ve seen that you have reverted the patches to go back to the original
(faster) behaviour, but why there is such a big performance hit by using
vertex arrays instead of glbegin/end? I thought vertex array should be
faster on modern hardware…

The “reverted” code also used a minor number of opengl calls for count > 2

data->glTranslatef(0.5f, 0.5f, 0.0f);
data->glVertexPointer(2, GL_FLOAT, 0, points);
data->glEnableClientState(GL_VERTEX_ARRAY);On Wed, Nov 6, 2013 at 6:10 AM, Sam Lantinga wrote:
data->glDrawArrays(GL_POINTS, 0, count);
data->glDisableClientState(GL_VERTEX_ARRAY);

data->glTranslatef(-0.5f, -0.5f, 0.0f);
data->glBegin(GL_POINTS);
for (i = 0; i < count; ++i) {

   data->glVertex2f(0.5f + points[i].x, 0.5f + points[i].y);

}
data->glEnd();

–
Bye,
Gabry

Andreas_Schiffler · November 6, 2013, 3:50pm

Yes, you are right - the SDL2_gfx implementation was a straight port
from the original Surface oriented code in SDL_gfx which is based on
writing pixels or rows of pixels. So one could definitely improve on the
performance of that library in the future by mapping all 2D operations
to their corresponding 3D-hardware-API implementation directly. BTW,
There is a lib that does 2D using the GPU: https://code.google.com/p/sdl-gpuOn 11/5/2013 11:27 PM, T. Joseph Carter wrote:

I’m not convinced that SDL2_gfx should be doing the equivalent of
putpixel and drawline directly to accelerated targets. It’s very
"software-rendery" and I know SDL’s 2D renderer is supposed to feel
like you’re working on a software renderer even when you’re not, but
I’d almost rather implement basic outline and filled polygons in the
software renderer and use flat shaded triangle fans in the hardware
renderers.

This isn’t even difficult to do, unless the shape you want to create
in 3D is a circle/ellipse. And then it’s not TOO bad because the
number of triangles needed to create a pixel-perfect “circle” is
actually deterministic if not terribly simple. It lends itself to an
easy implementation using vertex arrays and a simple loop if you’re
running some antique 3Dfx card card or something. (That’s
actually possible under X.org, but do those things even work under
Windows XP?)

Joseph

On Tue, Nov 05, 2013 at 08:30:46AM -0800, Andreas Schiffler wrote:
You were correct - these two revisions are the cause for the
performance regression.

SDL2_gfx relies on pixel and line rendering to compose the
primitives. All primitives seem to experience a slowdown, sometimes a
significant one.

$ ./testgfx.exe --renderer OpenGL
INFO: SDL2_gfx 1.0.0: testgfx
INFO: Platform: Windows
INFO: Renderer 0: opengl (Accelerated)
…

Primitive Orig HG Run1 Orig HG Run2 Orig HG Avg. -2 Rev
Run1 -2 Rev Run2 -2 Rev Avg Speedup with 7840&7842 reverted
Pixel 712,348 744,727 728,538 1,489,455 1,820,444
1,654,949 227%
Hline 390,095 390,095 390,095 431,158 431,158
431,158 111%
Vline 390,095 390,095 390,095 431,158 431,158
431,158 111%
Rectangle 372,364 390,095 381,229 1,638,400
1,638,400 1,638,400 430%
RoundedRectangle 26,771 26,597 26,684 53,195
51,848 52,521 197%
Box 1,024,000 1,170,286 1,097,143 1,365,333
1,638,400 1,501,867 137%
Line 372,364 390,095 381,229 455,111 431,158
443,135 116%
Circle 8,266 8,176 8,221 21,787 21,445 21,616
263%
AACircle 3,846 3,910 3,878 9,846 9,776 9,811
253%
FilledCircle 12,431 6,798 9,615 18,204 17,430
17,817 185%
Ellipse 6,715 6,715 6,715 17,504 17,210
17,357 258%
AAEllipse 3,710 3,720 3,715 9,320 9,153 9,236
249%
FilledEllipse 12,469 12,450 12,459 18,286 17,504
17,895 144%
Bezier 1,212 1,217 1,215 1,836 1,760 1,798 148%
Polygon 364,067 341,313 352,690 1,365,250
1,365,250 1,365,250 387%
AAPolygon 1,212 1,256 1,234 3,165 3,148 3,157
256%
FilledPolygon 4,137 4,146 4,142 6,169 5,769
5,969 144%
Trigon 364,089 356,174 360,131 1,365,333
1,260,308 1,312,821 365%
Arc 17,751 18,044 17,897 46,283 46,283 46,283
259%
Pie 210,051 207,392 208,722 348,596 341,333
344,965 165%
FilledPie 14,655 14,681 14,668 20,845 19,811
20,328 139%
ThickLine 618 616 617 1,648 1,631 1,639 266%
TOTAL    219%
On 11/4/2013 8:17 PM, Sam Lantinga wrote:

Offhand, I’m guessing it’s the line change to glDrawArrays() that’s
affecting you.

You should be able to test that hypothesis by backing out these two
changesets:
https://hg.libsdl.org/SDL/rev/a37d23ee1812
https://hg.libsdl.org/SDL/rev/7e9cd472a889

Does your program draw so many lines that this change causes
real-world performance issues for you?

On Mon, Nov 4, 2013 at 8:17 AM, Andreas Schiffler <@Andreas_Schiffler mailto:Andreas_Schiffler> wrote:

Yup - that sounds like a regression.
Could you open a bug on https://bugzilla.libsdl.org with repro
steps (either some test source code and/or steps using SDL2_gfx)
and your measurements numbers that show the difference.

On 11/4/2013 2:42 AM, Dark_Oppressor wrote:

Andreas Schiffler wrote:

Not really Smile

thickLineRGBA is slow; the algorithm is a port from a PostScript
renderer - it is functional & graphically correct, but not very
optimized

thickLineRGBA with a width of 1 should be special-cased to use
the
regular line algorithm - I’ll fix that in the next SDL2_gfx release

Cool, thanks Smile

At this point, I’m seeing a pretty big performance drop in both
thickLineRGBA and SDL_RenderDrawLine when moving from SDL 2.0.0
to 2.0.1. This was the case on Windows, OS X, and Linux. Does
this sound bug-like? Something has definitely changed, and I
don’t see how it could be on my end. All I changed was one
library, and the problem is on a variety of OSs, architectures,
and physical machines.

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

SDL mailing list
SDL at lists.libsdl.org <mailto: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

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

Mason_Wheeler · November 6, 2013, 6:24pm

Circle is actually incredibly simple with a shader.? Just draw a square, and then have the fragment shader discard all fragments whose pythagorean distance from the center is larger than the radius.

MasonOn Tuesday, November 5, 2013 11:27 PM, T. Joseph Carter wrote:

I’m not convinced that SDL2_gfx should be doing the equivalent of
putpixel and drawline directly to accelerated targets.? It’s very
"software-rendery" and I know SDL’s 2D renderer is supposed to feel
like you’re working on a software renderer even when you’re not, but
I’d almost rather implement basic outline and filled polygons in the
software renderer and use flat shaded triangle fans in the hardware
renderers.

This isn’t even difficult to do, unless the shape you want to create
in 3D is a circle/ellipse.? And then it’s not TOO bad because the
number of triangles needed to create a pixel-perfect “circle” is
actually deterministic if not terribly simple.? It lends itself to an
easy implementation using vertex arrays and a simple loop if you’re
running some antique 3Dfx card card or something.? ;)? (That’s
actually possible under X.org, but do those things even work under
Windows XP?)

Joseph

Dark_Oppressor · November 6, 2013, 10:52pm

Sam Lantinga wrote:

This should be fixed:https://hg.libsdl.org/SDL/rev/b339af982b62 (https://hg.libsdl.org/SDL/rev/b339af982b62)

Just tested this on Linux, and I see a pretty marked increase in performance. Thanks!

slouken · November 7, 2013, 12:48am

Great, thanks!On Wed, Nov 6, 2013 at 2:52 PM, Dark_Oppressor wrote:

Sam Lantinga wrote:

This should be fixed:https://hg.libsdl.org/SDL/rev/b339af982b62

Just tested this on Linux, and I see a pretty marked increase in
performance. Thanks!

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

T_Joseph_Carter · November 7, 2013, 3:34am

Does SDL-GPU fall back on software/surface code in the event of being
used on a software renderer?

JosephOn Wed, Nov 06, 2013 at 07:50:30AM -0800, Andreas Schiffler wrote:

Yes, you are right - the SDL2_gfx implementation was a straight port
from the original Surface oriented code in SDL_gfx which is based on
writing pixels or rows of pixels. So one could definitely improve on
the performance of that library in the future by mapping all 2D
operations to their corresponding 3D-hardware-API implementation
directly. BTW, There is a lib that does 2D using the GPU:
https://code.google.com/p/sdl-gpu

On 11/5/2013 11:27 PM, T. Joseph Carter wrote:

I’m not convinced that SDL2_gfx should be doing the equivalent of
putpixel and drawline directly to accelerated targets. It’s very
"software-rendery" and I know SDL’s 2D renderer is supposed to feel
like you’re working on a software renderer even when you’re not,
but I’d almost rather implement basic outline and filled polygons
in the software renderer and use flat shaded triangle fans in the
hardware renderers.

This isn’t even difficult to do, unless the shape you want to
create in 3D is a circle/ellipse. And then it’s not TOO bad
because the number of triangles needed to create a pixel-perfect
"circle" is actually deterministic if not terribly simple. It
lends itself to an easy implementation using vertex arrays and a
simple loop if you’re running some antique 3Dfx card card or
something. (That’s actually possible under X.org, but do those
things even work under Windows XP?)

Joseph

On Tue, Nov 05, 2013 at 08:30:46AM -0800, Andreas Schiffler wrote:

You were correct - these two revisions are the cause for the
performance regression.

SDL2_gfx relies on pixel and line rendering to compose the
primitives. All primitives seem to experience a slowdown,
sometimes a significant one.

$ ./testgfx.exe --renderer OpenGL
INFO: SDL2_gfx 1.0.0: testgfx
INFO: Platform: Windows
INFO: Renderer 0: opengl (Accelerated)
…

Primitive Orig HG Run1 Orig HG Run2 Orig HG Avg. -2
Rev Run1 -2 Rev Run2 -2 Rev Avg Speedup with
7840&7842 reverted
Pixel 712,348 744,727 728,538 1,489,455 1,820,444
1,654,949 227%
Hline 390,095 390,095 390,095 431,158 431,158
431,158 111%
Vline 390,095 390,095 390,095 431,158 431,158
431,158 111%
Rectangle 372,364 390,095 381,229 1,638,400
1,638,400 1,638,400 430%
RoundedRectangle 26,771 26,597 26,684 53,195
51,848 52,521 197%
Box 1,024,000 1,170,286 1,097,143 1,365,333
1,638,400 1,501,867 137%
Line 372,364 390,095 381,229 455,111 431,158
443,135 116%
Circle 8,266 8,176 8,221 21,787 21,445 21,616
263%
AACircle 3,846 3,910 3,878 9,846 9,776 9,811
253%
FilledCircle 12,431 6,798 9,615 18,204 17,430
17,817 185%
Ellipse 6,715 6,715 6,715 17,504 17,210
17,357 258%
AAEllipse 3,710 3,720 3,715 9,320 9,153 9,236
249%
FilledEllipse 12,469 12,450 12,459 18,286 17,504
17,895 144%
Bezier 1,212 1,217 1,215 1,836 1,760 1,798 148%
Polygon 364,067 341,313 352,690 1,365,250
1,365,250 1,365,250 387%
AAPolygon 1,212 1,256 1,234 3,165 3,148 3,157
256%
FilledPolygon 4,137 4,146 4,142 6,169 5,769
5,969 144%
Trigon 364,089 356,174 360,131 1,365,333
1,260,308 1,312,821 365%
Arc 17,751 18,044 17,897 46,283 46,283 46,283
259%
Pie 210,051 207,392 208,722 348,596 341,333
344,965 165%
FilledPie 14,655 14,681 14,668 20,845 19,811
20,328 139%
ThickLine 618 616 617 1,648 1,631 1,639 266%

TOTAL 219%

On 11/4/2013 8:17 PM, Sam Lantinga wrote:

Offhand, I’m guessing it’s the line change to glDrawArrays()
that’s affecting you.

You should be able to test that hypothesis by backing out these
two changesets:
https://hg.libsdl.org/SDL/rev/a37d23ee1812
https://hg.libsdl.org/SDL/rev/7e9cd472a889

Does your program draw so many lines that this change causes
real-world performance issues for you?

On Mon, Nov 4, 2013 at 8:17 AM, Andreas Schiffler <aschiffler at ferzkopp.net <mailto:aschiffler at ferzkopp.net>> wrote:

Yup - that sounds like a regression.
Could you open a bug on https://bugzilla.libsdl.org with repro
steps (either some test source code and/or steps using SDL2_gfx)
and your measurements numbers that show the difference.

On 11/4/2013 2:42 AM, Dark_Oppressor wrote:

Andreas Schiffler wrote:

Not really Smile

thickLineRGBA is slow; the algorithm is a port from a PostScript
renderer - it is functional & graphically correct, but not very
optimized

thickLineRGBA with a width of 1 should be special-cased
to use the
regular line algorithm - I’ll fix that in the next SDL2_gfx release

Cool, thanks Smile

At this point, I’m seeing a pretty big performance drop in both
thickLineRGBA and SDL_RenderDrawLine when moving from SDL 2.0.0
to 2.0.1. This was the case on Windows, OS X, and Linux. Does
this sound bug-like? Something has definitely changed, and I
don’t see how it could be on my end. All I changed was one
library, and the problem is on a variety of OSs, architectures,
and physical machines.

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

SDL mailing list
SDL at lists.libsdl.org <mailto: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

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

JonnyD · November 7, 2013, 1:26pm

That’s the thing about SDL_gpu. It’s an alternative to SDL_Renderer, as it
just uses OpenGL/GLES. The software fallback is whatever your OpenGL
driver supports, which would typically be horrible or nonexistent.

SDL_gpu is good if you can (or want to) assume decent GPU support. I
authored the project for a few reasons:
A consistent API for 2D effects that SDL_Renderer wouldn’t support.
Support for mixed OpenGL calls.
Clear, simple library code that can be modified easily.
An upgrade path from SDL1.2 to SDL2. It works with either and is great for
updating my old projects.

Jonny DOn Wed, Nov 6, 2013 at 10:34 PM, T. Joseph Carter < tjcarter at spiritsubstance.com> wrote:

Does SDL-GPU fall back on software/surface code in the event of being used
on a software renderer?

Joseph

On Wed, Nov 06, 2013 at 07:50:30AM -0800, Andreas Schiffler wrote:

Yes, you are right - the SDL2_gfx implementation was a straight port from
the original Surface oriented code in SDL_gfx which is based on writing
pixels or rows of pixels. So one could definitely improve on the
performance of that library in the future by mapping all 2D operations to
their corresponding 3D-hardware-API implementation directly. BTW, There is
a lib that does 2D using the GPU: https://code.google.com/p/sdl-gpu

On 11/5/2013 11:27 PM, T. Joseph Carter wrote:

I’m not convinced that SDL2_gfx should be doing the equivalent of
putpixel and drawline directly to accelerated targets. It’s very
"software-rendery" and I know SDL’s 2D renderer is supposed to feel like
you’re working on a software renderer even when you’re not, but I’d almost
rather implement basic outline and filled polygons in the software renderer
and use flat shaded triangle fans in the hardware renderers.

This isn’t even difficult to do, unless the shape you want to create in
3D is a circle/ellipse. And then it’s not TOO bad because the number of
triangles needed to create a pixel-perfect “circle” is actually
deterministic if not terribly simple. It lends itself to an easy
implementation using vertex arrays and a simple loop if you’re running some
antique 3Dfx card card or something. (That’s actually possible under
X.org, but do those things even work under Windows XP?)

Joseph

On Tue, Nov 05, 2013 at 08:30:46AM -0800, Andreas Schiffler wrote:

You were correct - these two revisions are the cause for the
performance regression.

SDL2_gfx relies on pixel and line rendering to compose the primitives.
All primitives seem to experience a slowdown, sometimes a significant one.

$ ./testgfx.exe --renderer OpenGL
INFO: SDL2_gfx 1.0.0: testgfx
INFO: Platform: Windows
INFO: Renderer 0: opengl (Accelerated)
…

Primitive Orig HG Run1 Orig HG Run2 Orig HG Avg. -2 Rev
Run1 -2 Rev Run2 -2 Rev Avg Speedup with 7840&7842 reverted
Pixel 712,348 744,727 728,538 1,489,455 1,820,444
1,654,949 227%
Hline 390,095 390,095 390,095 431,158 431,158
431,158 111%
Vline 390,095 390,095 390,095 431,158 431,158
431,158 111%
Rectangle 372,364 390,095 381,229 1,638,400 1,638,400
1,638,400 430%
RoundedRectangle 26,771 26,597 26,684 53,195 51,848
52,521 197%
Box 1,024,000 1,170,286 1,097,143 1,365,333 1,638,400
1,501,867 137%
Line 372,364 390,095 381,229 455,111 431,158
443,135 116%
Circle 8,266 8,176 8,221 21,787 21,445 21,616
263%
AACircle 3,846 3,910 3,878 9,846 9,776 9,811
253%
FilledCircle 12,431 6,798 9,615 18,204 17,430
17,817 185%
Ellipse 6,715 6,715 6,715 17,504 17,210 17,357
258%
AAEllipse 3,710 3,720 3,715 9,320 9,153 9,236
249%
FilledEllipse 12,469 12,450 12,459 18,286 17,504
17,895 144%
Bezier 1,212 1,217 1,215 1,836 1,760 1,798 148%
Polygon 364,067 341,313 352,690 1,365,250 1,365,250
1,365,250 387%
AAPolygon 1,212 1,256 1,234 3,165 3,148 3,157
256%
FilledPolygon 4,137 4,146 4,142 6,169 5,769 5,969
144%
Trigon 364,089 356,174 360,131 1,365,333 1,260,308
1,312,821 365%
Arc 17,751 18,044 17,897 46,283 46,283 46,283
259%
Pie 210,051 207,392 208,722 348,596 341,333 344,965
165%
FilledPie 14,655 14,681 14,668 20,845 19,811 20,328
139%
ThickLine 618 616 617 1,648 1,631 1,639 266%

TOTAL 219%

On 11/4/2013 8:17 PM, Sam Lantinga wrote:

Offhand, I’m guessing it’s the line change to glDrawArrays() that’s
affecting you.

You should be able to test that hypothesis by backing out these two
changesets:
https://hg.libsdl.org/SDL/rev/a37d23ee1812
https://hg.libsdl.org/SDL/rev/7e9cd472a889

Does your program draw so many lines that this change causes
real-world performance issues for you?

On Mon, Nov 4, 2013 at 8:17 AM, Andreas Schiffler < aschiffler at ferzkopp.net <mailto:aschiffler at ferzkopp.net>> wrote:

Yup - that sounds like a regression.
Could you open a bug on https://bugzilla.libsdl.org with repro
steps (either some test source code and/or steps using SDL2_gfx)
and your measurements numbers that show the difference.

On 11/4/2013 2:42 AM, Dark_Oppressor wrote:

Andreas Schiffler wrote:

Not really Smile

thickLineRGBA is slow; the algorithm is a port from a PostScript
renderer - it is functional & graphically correct, but not very
optimized

thickLineRGBA with a width of 1 should be special-cased to use the
regular line algorithm - I’ll fix that in the next SDL2_gfx release

Cool, thanks Smile

At this point, I’m seeing a pretty big performance drop in both
thickLineRGBA and SDL_RenderDrawLine when moving from SDL 2.0.0
to 2.0.1. This was the case on Windows, OS X, and Linux. Does
this sound bug-like? Something has definitely changed, and I
don’t see how it could be on my end. All I changed was one
library, and the problem is on a variety of OSs, architectures,
and physical machines.

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

SDL mailing list
SDL at lists.libsdl.org <mailto: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

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