> 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 --------------------------------------------------------------------- To unsubscribe, e-mail: nanogui-unsubscr...@linuxhacker.org For additional commands, e-mail: nanogui-h...@linuxhacker.org
