[<<] [<] Page 1 of 2 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: [FIX] add alpha channel into GdDrawImage software handling
From: "Greg Haerr" ####@####.#### Date: 10 Mar 2010 05:26:41 -0000 Message-Id: <05bc01cac012$417966e0$6564a8c0@winXP> > I added software alpha blending routine in GdDrawImage(). Mr Sung Joo - During the extensive porting of the Sony PSP and new ABGR framebuffer support, I relooked at the GdDrawImage code that you have gratefully contributed. There were still some consistency issues, mostly in documentation, on exactly the pixel and framebuffer format in use. I have heavily commented and in some cases rewritten the alpha channel drawing code, and would like you to have a look at it, and possibly test on the SCREEN_PIXTYPEs you tested below. I also added support for alpha blending in the new ABGR framebuffer format used in PSP. When handling images with alpha channel, for now we always convert to 0xAARRGGBB longword format, and then possibly reconvert or alpha-blend from there. All cases, including big and little endian are handled, but the fastest case, little endian .png files in MWIMAGE_RGB format, still do more bit-twiddling than is necessary. I am still looking into this, but didn't want to change everything all at once! The cases when converting to truecolor 3/3/2 or when #define ALPHABLEND 0 are still slow also. Thanks again for your contributions! Regards, Greg I have tested following case by using "nxview PNG_transparency_demonstration_2.png". ( only tested little endian. ) SCREEN_PIXTYPE = MWPF_TRUECOLOR0888 SCREEN_PIXTYPE = MWPF_TRUECOLOR888 SCREEN_PIXTYPE = MWPF_TRUECOLOR565 SCREEN_PIXTYPE = MWPF_TRUECOLOR555 SCREEN_PIXTYPE = MWPF_TRUECOLOR8888 Regards | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: Re: [FIX] add alpha channel into GdDrawImage software handling
From: ####@####.#### Date: 10 Mar 2010 06:32:55 -0000 Message-Id: <eab382740e22bb1f8f92c3526ae2ea56@a51019> > would like you to have a look at it, and possibly test on the SCREEN_PIXTYPEs you tested below. Mr Haerr. Sure, I am willing to test it. Your rewritten code is very smart. The more you rewrite, the smarter code is. Also, I agree that bit-rwiddling is not good. I am wondering how GdDrawImage() is implemented without bit-twidlling. Regards, Sung Joo -----Original Message----- From: "Greg ####@####.#### To: ####@####.#### Cc: ####@####.#### Sent: 10-03-10(μ) 14:26:36 Subject: Re: [FIX] add alpha channel into GdDrawImage software handling > I added software alpha blending routine in GdDrawImage(). Mr Sung Joo - During the extensive porting of the Sony PSP and new ABGR framebuffer support, I relooked at the GdDrawImage code that you have gratefully contributed. There were still some consistency issues, mostly in documentation, on exactly the pixel and framebuffer format in use. I have heavily commented and in some cases rewritten the alpha channel drawing code, and would like you to have a look at it, and possibly test on the SCREEN_PIXTYPEs you tested below. I also added support for alpha blending in the new ABGR framebuffer format used in PSP. When handling images with alpha channel, for now we always convert to 0xAARRGGBB longword format, and then possibly reconvert or alpha-blend from there. All cases, including big and little endian are handled, but the fastest case, little endian .png files in MWIMAGE_RGB format, still do more bit-twiddling than is necessary. I am still looking into this, but didn't want to change everything all at once! The cases when converting to truecolor 3/3/2 or when #define ALPHABLEND 0 are still slow also. Thanks again for your contributions! Regards, Greg I have tested following case by using "nxview PNG_transparency_demonstration_2.png". ( only tested little endian. ) SCREEN_PIXTYPE = MWPF_TRUECOLOR0888 SCREEN_PIXTYPE = MWPF_TRUECOLOR888 SCREEN_PIXTYPE = MWPF_TRUECOLOR565 SCREEN_PIXTYPE = MWPF_TRUECOLOR555 SCREEN_PIXTYPE = MWPF_TRUECOLOR8888 Regards | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: [nanogui] Re: Re: [FIX] add alpha channel into GdDrawImage software handling
From: ####@####.#### Date: 11 Mar 2010 04:47:02 -0000 Message-Id: <ce8e57d46643a0818432954cc56f0d3e@a51159> Mr Haerr 1) I have tested modified GdDrawImage() code on SCREEN_PIXTYPEs below. ( only for little endian. ) SCREEN_PIXTYPE = MWPF_TRUECOLOR8888 SCREEN_PIXTYPE = MWPF_TRUECOLOR0888 SCREEN_PIXTYPE = MWPF_TRUECOLOR888 SCREEN_PIXTYPE = MWPF_TRUECOLOR565 SCREEN_PIXTYPE = MWPF_TRUECOLOR555 It works well. (perfectly) 2) I have modified a few. ( GdDrawImage() ) modifying struct RGB565,RGB555 field order on big endian. ( conditional compile ) In case rgb565/rgb555 for big-endian, I guess that a byte swap operation which is the last step of GdDrawImage() is not proper. I think that it is proper to modify like your rewritten struct ARGB. 3) Additionaly, test for tiff alpha channel image have been completed. It works well. You can download TIFF test image from ftp://ftp.remotesensing.org/pub/libtiff/pics-3.8.0.tar.gz ( visit on http://www.remotesensing.org/libtiff/images.html. ) pics-3.8.0.tar.gz has strike.tiff that has alpha channel. ( bowling strike image. ) 4) very trivial patch code for korean language. MWTF_DBCS_KSC -> MWTF_DBCS_EUCKR in 1demo.c p.s : I suggest a small tip. I have ever tried to construct a big endian test environment. It may be possoble by using QEMU. A simple big-endian program can run on i386 pc by QEMU. ex) $file a.out a.out: ELF 32-bit MSB executable, ARM, version 1, statically linked, for GNU/Linux 2.0.0, not stripped $ qemu-armeb a.out hello But, complex program require kernel image for QEMU. ( I guess ) If you are good at building linux kernel, you can fully test microwindow in big-endian environment. ex) $ qemu-system-sparc -kernel vmlinux-2.6.11+tcx -initrd linux.img but, I have no knowledge about linux kernel build. If anyone can do it and it is completed successfully, please inform a mailling list. Regards, Sung Joo [Content type application/x-gzip not shown. Download] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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: ####@####.#### | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: [nanogui] Re: Re: [FIX] add alpha channel into GdDrawImage software handling
From: "Greg Haerr" ####@####.#### Date: 12 Mar 2010 05:17:55 -0000 Message-Id: <0d1b01cac1a3$5dd2b340$6564a8c0@winXP> : 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. No, I think we need to be completely accurate. This divide is not the performance problem in the drawing loop, it is the execution of the switch() statement. Regards, Greg | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: [nanogui] Re: Re: [FIX] add alpha channel into GdDrawImage software handling
From: "Greg Haerr" ####@####.#### Date: 12 Mar 2010 05:47:10 -0000 Message-Id: <0d5701cac1a7$7288d630$6564a8c0@winXP> > 1) I have tested modified GdDrawImage() code on SCREEN_PIXTYPEs below. > ( only for little endian. ) SCREEN_PIXTYPE = MWPF_TRUECOLOR8888 SCREEN_PIXTYPE = MWPF_TRUECOLOR0888 SCREEN_PIXTYPE = MWPF_TRUECOLOR888 SCREEN_PIXTYPE = MWPF_TRUECOLOR565 SCREEN_PIXTYPE = MWPF_TRUECOLOR555 > It works well. (perfectly) Great! > 2) I have modified a few. ( GdDrawImage() ) > modifying struct RGB565,RGB555 field order on big endian. ( > conditional compile ) > In case rgb565/rgb555 for big-endian, I guess that a byte swap > operation which is the last > step of > GdDrawImage() is not proper. I think that it is proper to > modify like your > rewritten struct ARGB. No, I originally wrote it like that, but I don't think so. You are saying that struct { unsigned char r:5; }; allocates the TOP (MSB) bits in big endian? I don't think so. I agree it allocates the top BYTE in big endian, but the bits in the byte are still allocated from 0 up, not 7 down. This will still allocate the LOWER 5 bits in either endian, I think. So the issue is that bytes are re-ordered, but NOT bits, in little vs big endian. Because of this, I ordered the bits the same way as little endian, and then byte-swapped them on write. Obviously we need to look at compiler output to know how bits are ordered on big-endian. Comments? > 3) Additionaly, test for tiff alpha channel image have been completed. > It works well. Thanks, I'll add some test tiff images to git. > 4) very trivial patch code for korean language. > MWTF_DBCS_KSC -> MWTF_DBCS_EUCKR in 1demo.c Done. > I have ever tried to construct a big endian test environment. It may be > possoble by using QEMU. > A simple big-endian program can run on i386 pc by QEMU. I will look into this! Regards, Greg | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: Re: [nanogui] Re: Re: [FIX] add alpha channel into GdDrawImage software handling
From: ####@####.#### Date: 12 Mar 2010 05:55:48 -0000 Message-Id: <cb75e745c0421bffb5ba289a7524dac7@a51019> Mr Haerr > No, I think we need to be completely accurate. I agree it. > This divide is not the performance problem in the drawing loop, it is the execution of the switch() statement. But, I have different opinions on that issue. - The every pixel is divided by 255 in the drawing loop. ( alphablend case ) - In case ARM, ARM core do not support hardware for division. Instead, compiler implement a division by calling software routine in C library. The standard integer division routine supported by C library takes 20~100 cycle. It depens on ARM processor family. Anyway, I agree that an accuracy is the most important , too. Regards, Sung Joo -----Original Message----- From: "Greg ####@####.#### To: "Sung Joo, ####@####.#### Cc: ####@####.#### Sent: 10-03-12(κΈ) 14:17:51 Subject: Re: [nanogui] Re: Re: [FIX] add alpha channel into GdDrawImage software handling : 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. No, I think we need to be completely accurate. This divide is not the performance problem in the drawing loop, it is the execution of the switch() statement. Regards, Greg --------------------------------------------------------------------- To unsubscribe, e-mail: ####@####.#### For additional commands, e-mail: ####@####.#### | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: Re: [nanogui] Re: Re: [FIX] add alpha channel into GdDrawImage software handling
From: "Greg Haerr" ####@####.#### Date: 12 Mar 2010 06:01:42 -0000 Message-Id: <0dc501cac1a9$7c072fc0$6564a8c0@winXP> : - The every pixel is divided by 255 in the drawing loop. ( alphablend case ) : - In case ARM, ARM core do not support hardware for division. Instead, compiler implement a division by calling software routine in C library. The standard integer division routine supported by C library takes 20~100 cycle. It depens on ARM processor family. In that case, perhaps we should use a macro to perform the alphablending, which could then be /255 for accuracy, or >>8 for speed, and set it in device.h. Regards, Greg | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: Re: [nanogui] Re: Re: [FIX] add alpha channel into GdDrawImage software handling
From: ####@####.#### Date: 12 Mar 2010 11:17:59 -0000 Message-Id: <c4bc14e563bcc2cdb8e7be0196428d25@a51105> Endian confuse me. I am studing again. > You are saying that > struct { > unsigned char r:5; > }; > allocates the TOP (MSB) bits in big endian? Yes, in case 11110000(b)=0xF0 , r is 0x1e. please refer to http://www.linuxjournal.com/node/6788/print. > I don't think so. > I agree it allocates the top BYTE in big endian, but the > bits in the byte are still allocated from 0 up, not 7 down. > This will still allocate the LOWER 5 bits in either endian,I think. > So the issue is that bytes are re-ordered, but NOT bits, in little vs big endian. typedef union { struct { unsigned char r:5 } r; unsigned char v; } BF BF c; c.v = 0xF0; // 11110000 then, in a big endian c.f.r = 0x1e in a little endian c.f.r = 0x10 It is tested on QEMU with arm big-endian. ( $ qemu-armeb a.out ) Regards, Sung Joo | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 2 [>] [>>] |