Iphone sdl blitting performance

[Andy_Mutton]

Hi there,

I’m sure this topic has come up in some way or another many times over
the past few weeks, but I just wanted to check…

Should I be getting ~5fps for an application that blits SDL_Surfaces
the old fashioned way on an iPhone?

I’m trying to port a fairly old piece of code to run on my new toy and
I’m getting absolutely HORRENDOUS performance out of it. It’s not a
sprite based application (everything is done through pixel
manipulation on surfaces) but I would still expect something better
than the awful trundling I’m getting.

I’m aware that this doesn’t sit very well with the new-school way of
doing things, but rewriting something like this in a new-school way
would probably ruin the awesome style (what’s the point in blitting
pixels?) as well as take much more time than I want to give.

Is there anything that can be done to get this usable again? Should I
be setting some render_option like
SDL_MAKE_LEGACY_2D_SURFACE_BLITS_AWESOME or something?

Would I be better served removing the legacy init and flips and
instead recreating a texture every frame with my surface? From
reading, that seems to be what the compatibility more stuff does - so
no improvement there?

What about rewriting texture content with a stream of pixels? Or
manipulating texture pixels directly?

Also, it’s really cruel to say that iPhone dev has to be done from 1.3
and then to have NO documentation anywhere describing the way things
work now. Cruel I say!

Cheers,
Andy

[Holmes_Futrell]

Hi Andy

5 frames per second … that actually sounds about right. The reason is
that since the iPhone is using OpenGL ES, old fashioned blits must use
glTexSubImage2D, which is extremely slow.

Would you be better off getting rid of the legacy init and flips and
making a texture yourself? Essentially that’s what glTexSubImage2D is
actually doing, so my guess would be no.

The only ways I can see that you could improve performance would be:

• move the code to use SDL_Textures
• get somebody to write an SDL video driver for iPhone that uses
  CoreGraphics or the private direct pixel access framework instead of
  OpenGL ES.

In terms of documentation, read the Readme.iPhoneOS file if you haven’t
though – that does explain a lot of things. But yeah, I wasn’t
selected for GSoC and I can’t really afford (financially) to work on the
project otherwise, so yeah, sorry for the lack of updates.

• Holmes

Andy Mutton wrote:> Hi there,

I’m sure this topic has come up in some way or another many times over
the past few weeks, but I just wanted to check…

Should I be getting ~5fps for an application that blits SDL_Surfaces
the old fashioned way on an iPhone?

I’m trying to port a fairly old piece of code to run on my new toy and
I’m getting absolutely HORRENDOUS performance out of it. It’s not a
sprite based application (everything is done through pixel
manipulation on surfaces) but I would still expect something better
than the awful trundling I’m getting.

I’m aware that this doesn’t sit very well with the new-school way of
doing things, but rewriting something like this in a new-school way
would probably ruin the awesome style (what’s the point in blitting
pixels?) as well as take much more time than I want to give.

Is there anything that can be done to get this usable again? Should I
be setting some render_option like
SDL_MAKE_LEGACY_2D_SURFACE_BLITS_AWESOME or something?

Would I be better served removing the legacy init and flips and
instead recreating a texture every frame with my surface? From
reading, that seems to be what the compatibility more stuff does - so
no improvement there?

What about rewriting texture content with a stream of pixels? Or
manipulating texture pixels directly?

Also, it’s really cruel to say that iPhone dev has to be done from 1.3
and then to have NO documentation anywhere describing the way things
work now. Cruel I say!

Cheers,
Andy

---

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

[Andy_Mutton]

Gah!! I had a feeling you were going to say something like that. And
there was me so pleased when I got it running so quickly in the
simulator.

Changing it to use textures is definitely not going to work. Unless I
make 1 solid black square texture and redraw the entire screen with it
every time - probably not a good idea.

I guess I could look at the Core Graphics stuff myself, but, as you
say, who has the time?!

Thanks anyway. It’s cool that SDL even works on the iPhone. I’ll keep
playing and see how I go.On Mon, Jun 15, 2009 at 5:27 PM, Holmes Futrell wrote:

Hi Andy

5 frames per second … that actually sounds about right. ?The reason is
that since the iPhone is using OpenGL ES, old fashioned blits must use
glTexSubImage2D, which is extremely slow.
Would you be better off getting rid of the legacy init and flips and making
a texture yourself? ?Essentially that’s what glTexSubImage2D is actually
doing, so my guess would be no.

The only ways I can see that you could improve performance would be:

• move the code to use SDL_Textures
• get somebody to write an SDL video driver for iPhone that uses
  CoreGraphics or the private direct pixel access framework instead of OpenGL
  ES.

In terms of documentation, read the Readme.iPhoneOS file if you haven’t
though – that does explain a lot of things. ?But yeah, I wasn’t selected
for GSoC and I can’t really afford (financially) to work on the project
otherwise, so yeah, sorry for the lack of updates.

• Holmes

Andy Mutton wrote:

Hi there,

I’m sure this topic has come up in some way or another many times over
the past few weeks, but I just wanted to check…

Should I be getting ~5fps for an application that blits SDL_Surfaces
the old fashioned way on an iPhone?

I’m trying to port a fairly old piece of code to run on my new toy and
I’m getting absolutely HORRENDOUS performance out of it. It’s not a
sprite based application (everything is done through pixel
manipulation on surfaces) but I would still expect something better
than the awful trundling I’m getting.

I’m aware that this doesn’t sit very well with the new-school way of
doing things, but rewriting something like this in a new-school way
would probably ruin the awesome style (what’s the point in blitting
pixels?) as well as take much more time than I want to give.

Is there anything that can be done to get this usable again? Should I
be setting some render_option like
SDL_MAKE_LEGACY_2D_SURFACE_BLITS_AWESOME or something?

Would I be better served removing the legacy init and flips and
instead recreating a texture every frame with my surface? From
reading, that seems to be what the compatibility more stuff does - so
no improvement there?

What about rewriting texture content with a stream of pixels? Or
manipulating texture pixels directly?

Also, it’s really cruel to say that iPhone dev has to be done from 1.3
and then to have NO documentation anywhere describing the way things
work now. Cruel I say!

Cheers,
Andy

---

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

[Donny_Viszneki]

Can’t he use old-school software surfaces to do his compositing and
then send the result to the graphics card? Someone should write a
video back end for that.On Mon, Jun 15, 2009 at 6:40 PM, Andy Mutton<andy.mutton at gmail.com> wrote:

Gah!! I had a feeling you were going to say something like that. And
there was me so pleased when I got it running so quickly in the
simulator.

Changing it to use textures is definitely not going to work. Unless I
make 1 solid black square texture and redraw the entire screen with it
every time - probably not a good idea.

I guess I could look at the Core Graphics stuff myself, but, as you
say, who has the time?!

Thanks anyway. It’s cool that SDL even works on the iPhone. I’ll keep
playing and see how I go.

On Mon, Jun 15, 2009 at 5:27 PM, Holmes Futrell wrote:

Hi Andy

5 frames per second … that actually sounds about right. ?The reason is
that since the iPhone is using OpenGL ES, old fashioned blits must use
glTexSubImage2D, which is extremely slow.
Would you be better off getting rid of the legacy init and flips and making
a texture yourself? ?Essentially that’s what glTexSubImage2D is actually
doing, so my guess would be no.

The only ways I can see that you could improve performance would be:

• move the code to use SDL_Textures
• get somebody to write an SDL video driver for iPhone that uses
  CoreGraphics or the private direct pixel access framework instead of OpenGL
  ES.

In terms of documentation, read the Readme.iPhoneOS file if you haven’t
though – that does explain a lot of things. ?But yeah, I wasn’t selected
for GSoC and I can’t really afford (financially) to work on the project
otherwise, so yeah, sorry for the lack of updates.

• Holmes

Andy Mutton wrote:

Hi there,

I’m sure this topic has come up in some way or another many times over
the past few weeks, but I just wanted to check…

Should I be getting ~5fps for an application that blits SDL_Surfaces
the old fashioned way on an iPhone?

I’m trying to port a fairly old piece of code to run on my new toy and
I’m getting absolutely HORRENDOUS performance out of it. It’s not a
sprite based application (everything is done through pixel
manipulation on surfaces) but I would still expect something better
than the awful trundling I’m getting.

I’m aware that this doesn’t sit very well with the new-school way of
doing things, but rewriting something like this in a new-school way
would probably ruin the awesome style (what’s the point in blitting
pixels?) as well as take much more time than I want to give.

Is there anything that can be done to get this usable again? Should I
be setting some render_option like
SDL_MAKE_LEGACY_2D_SURFACE_BLITS_AWESOME or something?

Would I be better served removing the legacy init and flips and
instead recreating a texture every frame with my surface? From
reading, that seems to be what the compatibility more stuff does - so
no improvement there?

What about rewriting texture content with a stream of pixels? Or
manipulating texture pixels directly?

Also, it’s really cruel to say that iPhone dev has to be done from 1.3
and then to have NO documentation anywhere describing the way things
work now. Cruel I say!

Cheers,
Andy

---

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

–
http://codebad.com/

[Donny_Viszneki]

Graphics card?

rolls eyes

Sorry. Wherever the bottleneck is, send it through that.On Mon, Jun 15, 2009 at 7:26 PM, Donny Viszneki<@Donny_Viszneki> wrote:

Can’t he use old-school software surfaces to do his compositing and
then send the result to the graphics card? Someone should write a
video back end for that.

–
http://codebad.com/

[Holmes_Futrell]

That is actually what is going on.

The last time I checked when SDL 1.3 uses older style blitting it
establishes a surface for the screen whose dirty regions are sent to the
GPU when its time for the screen to actually draw (using
glTexSubImage2D). So far as I know, this is the fastest way to go from
software -> hardware using OpenGL ES, and it’s still far far too slow.

• Holmes

Donny Viszneki wrote:> Can’t he use old-school software surfaces to do his compositing and

then send the result to the graphics card? Someone should write a
video back end for that.

On Mon, Jun 15, 2009 at 6:40 PM, Andy Mutton<andy.mutton at gmail.com> wrote:

Gah!! I had a feeling you were going to say something like that. And
there was me so pleased when I got it running so quickly in the
simulator.

Changing it to use textures is definitely not going to work. Unless I
make 1 solid black square texture and redraw the entire screen with it
every time - probably not a good idea.

I guess I could look at the Core Graphics stuff myself, but, as you
say, who has the time?!

Thanks anyway. It’s cool that SDL even works on the iPhone. I’ll keep
playing and see how I go.

On Mon, Jun 15, 2009 at 5:27 PM, Holmes Futrell<@Holmes_Futrell> wrote:

Hi Andy

5 frames per second … that actually sounds about right. The reason is
that since the iPhone is using OpenGL ES, old fashioned blits must use
glTexSubImage2D, which is extremely slow.
Would you be better off getting rid of the legacy init and flips and making
a texture yourself? Essentially that’s what glTexSubImage2D is actually
doing, so my guess would be no.

The only ways I can see that you could improve performance would be:

• move the code to use SDL_Textures
• get somebody to write an SDL video driver for iPhone that uses
  CoreGraphics or the private direct pixel access framework instead of OpenGL
  ES.

In terms of documentation, read the Readme.iPhoneOS file if you haven’t
though – that does explain a lot of things. But yeah, I wasn’t selected
for GSoC and I can’t really afford (financially) to work on the project
otherwise, so yeah, sorry for the lack of updates.

• Holmes

Andy Mutton wrote:

Hi there,

I’m sure this topic has come up in some way or another many times over
the past few weeks, but I just wanted to check…

Should I be getting ~5fps for an application that blits SDL_Surfaces
the old fashioned way on an iPhone?

I’m trying to port a fairly old piece of code to run on my new toy and
I’m getting absolutely HORRENDOUS performance out of it. It’s not a
sprite based application (everything is done through pixel
manipulation on surfaces) but I would still expect something better
than the awful trundling I’m getting.

I’m aware that this doesn’t sit very well with the new-school way of
doing things, but rewriting something like this in a new-school way
would probably ruin the awesome style (what’s the point in blitting
pixels?) as well as take much more time than I want to give.

Is there anything that can be done to get this usable again? Should I
be setting some render_option like
SDL_MAKE_LEGACY_2D_SURFACE_BLITS_AWESOME or something?

Would I be better served removing the legacy init and flips and
instead recreating a texture every frame with my surface? From
reading, that seems to be what the compatibility more stuff does - so
no improvement there?

What about rewriting texture content with a stream of pixels? Or
manipulating texture pixels directly?

Also, it’s really cruel to say that iPhone dev has to be done from 1.3
and then to have NO documentation anywhere describing the way things
work now. Cruel I say!

Cheers,
Andy

---

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

[Donny_Viszneki]

glTexSubImage2D is typically significantly slower than even glTexImage2DOn Mon, Jun 15, 2009 at 7:50 PM, Holmes Futrell wrote:

The last time I checked when SDL 1.3 uses older style blitting it
establishes a surface for the screen whose dirty regions are sent to the GPU
when its time for the screen to actually draw (using glTexSubImage2D). ?So
far as I know, this is the fastest way to go from software -> hardware using
OpenGL ES, and it’s still far far too slow.

–
http://codebad.com/

[Andy_Mutton]

Well, I just tried every quick thing I can think of, even though they
were all never going to work.

SDL_UpdateTexture is too slow. SDL_CreateTexture (and destroy) is too
slow. SDL_LockTexture is too slow.

Basically, blitting every frame with textures and the OpenGL ES
backend is never going to work on an iPhone as far as I can tell.
Holmes, you are bang on! It’s just too slow.

So yeah… I guess writing the 2d video backend for the iPhone is the
only answer. Or just porting my code to Objective C and not using SDL.
It’s just blitting a bunch of pixels. Not exactly heavily dependent on
SDL APIs.On Tue, Jun 16, 2009 at 12:27 AM, Donny Viszneki<donny.viszneki at gmail.com> wrote:

On Mon, Jun 15, 2009 at 7:26 PM, Donny Viszneki<donny.viszneki at gmail.com> wrote:

Can’t he use old-school software surfaces to do his compositing and
then send the result to the graphics card? Someone should write a
video back end for that.

Graphics card?

rolls eyes

Sorry. Wherever the bottleneck is, send it through that.

–
http://codebad.com/

[Holmes_Futrell]

Is it really? In that case I guess Andy could try his luck with that.
Maybe try benchmarking it first before committing to make any changes
though

• Holmes

Donny Viszneki wrote:> On Mon, Jun 15, 2009 at 7:50 PM, Holmes Futrell<@Holmes_Futrell> wrote:

The last time I checked when SDL 1.3 uses older style blitting it
establishes a surface for the screen whose dirty regions are sent to the GPU
when its time for the screen to actually draw (using glTexSubImage2D). So
far as I know, this is the fastest way to go from software -> hardware using
OpenGL ES, and it’s still far far too slow.

glTexSubImage2D is typically significantly slower than even glTexImage2D

[Andy_Mutton]

Well then, I may just go direct to OpenGL and try it. I still think
it’s going to be super-slow though. It’s a pretty big texture really,
especially if I’m updating it every frame.

Don’t worry about me wasting my time on crazy untested rewrites
Holmes. I’m testing all of this in a separate harness that just plays
with a screen-sized texture.

Holmes Futrell wrote:> Is it really? In that case I guess Andy could try his luck with that.

Maybe try benchmarking it first before committing to make any changes
though

• Holmes

Donny Viszneki wrote:

On Mon, Jun 15, 2009 at 7:50 PM, Holmes Futrell wrote:

The last time I checked when SDL 1.3 uses older style blitting it
establishes a surface for the screen whose dirty regions are sent to the GPU
when its time for the screen to actually draw (using glTexSubImage2D). So
far as I know, this is the fastest way to go from software -> hardware using
OpenGL ES, and it’s still far far too slow.

glTexSubImage2D is typically significantly slower than even glTexImage2D