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


[<<] [<] 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 [>] [>>]


Powered by ezmlm-browse 0.20.