SDL internal: blit from 24-bit RGB source never optimized

SDL Development
1

Hi,

I’m working on an application which displays a sequence of JPEG files; jpeg
decoding is done with the usual libjpeg, which output format is RGB. I’m
trying to blit the RGB data onto a 16-bit surface, but browsing through the
SDL code, it seems that there is no optimized blitter implemented for this
conversion, so the ‘fallback’ blitNtoN is used here.

Source format is 24 bpp rgba 0x000000ff 0x0000ff00 0x00ff0000 0x00000000

Is blitNtoN the fastest blitter for all RGB sources in all cases, or are
optimized blitters for this source format just not yet implemented ?

Regards,

2

Are you really using 24bpp surfaces or are they actually 32bpp (with 1 byte
ignored)?
Keep in mind that 3 byte per pixel format will always be much slower than 4
bytes per pixel, and the blitter selection code states /* Default for 24-bit
RGB source, never optimized */.
There are optimized C and asm blitters for 32bpp->16bpp, but you should use
surface format with masks R=0x00ff0000 G=0x0000ff00 B=0x000000ff.

And no, BlitNtoN() is the slowest possible blitter :).

-Alex.> ----- Original Message -----

From: sdl@zevv.nl
Sent: Monday, September 26, 2005 3:23 PM
To: sdl at libsdl.org
Subject: [SDL] SDL internal: blit from 24-bit RGB source never optimized

Hi,

I’m working on an application which displays a sequence of JPEG files; jpeg
decoding is done with the usual libjpeg, which output format is RGB. I’m
trying to blit the RGB data onto a 16-bit surface, but browsing through the
SDL code, it seems that there is no optimized blitter implemented for this
conversion, so the ‘fallback’ blitNtoN is used here.

Source format is 24 bpp rgba 0x000000ff 0x0000ff00 0x00ff0000 0x00000000

Is blitNtoN the fastest blitter for all RGB sources in all cases, or are
optimized blitters for this source format just not yet implemented ?

Regards,

3

Are you really using 24bpp surfaces or are they actually 32bpp (with 1 byte
ignored)?

Yes, really 24 BPP, since the output format from libjpeg forces me to use
that.

Keep in mind that 3 byte per pixel format will always be much slower than 4
bytes per pixel, and the blitter selection code states /* Default for 24-bit
RGB source, never optimized */.

That’s exactly what I found in the code, and that’s why I asked. It should
be possible to use some acceleration here, although it is not the fastest
format ?

There are optimized C and asm blitters for 32bpp->16bpp, but you should use
surface format with masks R=0x00ff0000 G=0x0000ff00 B=0x000000ff.

Yes, I found those, so I now make one extra pass after the JPEG
decompression where I shuffle the data from 24 to 32 bit, and swap the R and
B values; which is a huge speedup.

And no, BlitNtoN() is the slowest possible blitter :).

That’s what I found out the painful way :slight_smile:

Thanks for the info,–
:wq
^X^Cy^K^X^C^C^C^C

4

sdl at zevv.nl wrote:

It should be possible to use some acceleration here,
although it is not the fastest format ?

Certainly. You might even be able to get your implementation accepted into
SDL :P. Seriously though, I have yet to get a single response to the patches
I sent.

Yes, I found those, so I now make one extra pass after the JPEG
decompression where I shuffle the data from 24 to 32 bit, and swap
the R and B values; which is a huge speedup.

Exactly what I would do too. It is also a better way of doing things for the
long run if you have to render the same JPEGs multiple times.

-Alex.