nanogui: Re: [FIX] add alpha channel into GdDrawImage software handling


Previous by date: 11 Mar 2010 05:08:51 -0000 Re: [FIX] add alpha channel into GdDrawImage software handling, Sung Joo, Byun
Next by date: 11 Mar 2010 05:08:51 -0000 Re: Nano-X For PSP, yut616
Previous in thread: 11 Mar 2010 05:08:51 -0000 Re: [FIX] add alpha channel into GdDrawImage software handling, Sung Joo, Byun
Next in thread: 11 Mar 2010 05:08:51 -0000 Re: [FIX] add alpha channel into GdDrawImage software handling, Greg Haerr

Subject: RE: [nanogui] Re: Re: [FIX] add alpha channel into GdDrawImage software handling
From: ####@####.####
Date: 11 Mar 2010 05:08:51 -0000
Message-Id: <c3ff2b4b2988312d7911df70bbc35730@i61811>

Mr Haerr
 
How about changing from (color/255) to (color>>8) in GdDrawImage() ?
 
Although it is not an accurate value, but it has the advantage of performance. 
 
Regards
 
Sung Joo
 
-----Original Message-----
From: "Greg ####@####.#### 
To: "Sung Joo, ####@####.####
Cc: ####@####.####
Sent: 10-03-10(수) 16:37:02
Subject: [nanogui] Re: Re: [FIX] add alpha channel into GdDrawImage software handling
> 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: ####@####.####
For additional commands, e-mail: ####@####.####

Previous by date: 11 Mar 2010 05:08:51 -0000 Re: [FIX] add alpha channel into GdDrawImage software handling, Sung Joo, Byun
Next by date: 11 Mar 2010 05:08:51 -0000 Re: Nano-X For PSP, yut616
Previous in thread: 11 Mar 2010 05:08:51 -0000 Re: [FIX] add alpha channel into GdDrawImage software handling, Sung Joo, Byun
Next in thread: 11 Mar 2010 05:08:51 -0000 Re: [FIX] add alpha channel into GdDrawImage software handling, Greg Haerr


Powered by ezmlm-browse 0.20.