nanogui: Re: [FIX] add alpha channel into GdDrawImage software handling
Subject:
Re: Re: [FIX] add alpha channel into GdDrawImage software handling
From:
"Greg Haerr" ####@####.####
Date:
10 Mar 2010 07:37:08 -0000
Message-Id: <06a201cac024$7a9e49b0$6564a8c0@winXP>
> Sure, I am willing to test it.
> Your rewritten code is very smart. The more you rewrite, the smarter code
> is.
Thanks, let me know if it still works! I hope so :)
> Also, I agree that bit-rwiddling is not good.
> I am wondering how GdDrawImage() is implemented without bit-twidlling.
The extra bit-twiddling that concerns me is that
first we grab the data from the image array
using cr = *data++. Then, use and if statement
if(rgborder) ... to rearrange the data to ARGB
format, before we check for alpha. Then
we check for alpha by (cr >> 24).
If alpha == 0, we didn't need the above rearrange
to ARGB, since the pixel is transparent. If the
framebuffer type isn't truecolor[0]888, then
we have to convert back to ABGR format,
which is very slow.
Finally, for the fastest most common alpha channel
case, consider .png images, which are always
in MWIMAGE_RGB format (RGBA). In the
common little-endian case, we if(rgborder)
have to both cr = *data++, which moves four
bytes, and then re-order to ARGB. Perhaps
it would be quicker to use something like
the 32bpp non-alpha code below, which uses
cr = MWRGB(image[3],image[0],image[1],image[2])
so that we don't have to move 4 bytes twice.
These are the issues I was thinking about. We will
have to look at the code produced by the compiler
in both -O3 mode to determine what the fastest
method should be. In addition, YuTao was saying
that they needed to move the switch() statement
out of the inner loop for speed, as it was too slow
for their new WDTV box. (we have them here in USA,
pretty cool!)
Regards,
Greg
