nanogui: Thread: Alpha blending problem

I started to use latest FLTK 1.1.7-T5520 and this one has implemented alpha blending (new, different ?).
Anyway, it does not work properly with Microwindows nano-X and works fine on X11.

The images (PNG) are blended improperly (some improperly colored pixels).
The same program worked fine with older FLTK-1.1.7.

Can someone point me in some direction on how to fix/debug Microwindows to take care of this problem?

I am using 16 bit depth (RGB 5:6:5).

Matin

I have some more information.
The Alpha blending is done by the FLTK and not by the Microwindows.
Then, the FLTK calls the XputImage() to do the drawing with the blended image.
The only problem with the image is that the blended pixels which should be black are transparent and possibly other problems that I cannot see.
This appears to be one of those cases where the color conversion from X11 to Microwindows colors (255 <-> 0) does not work.
I thought this was already fixed but there must be another case.

I believe that the black color is 0, what is the transparent color?
Any other suggestions where to look for this problem?

Martin

I fixed (hacked) this problem (in nxlib-0.45) and this is what I have
found.
This is really a XGetImage and XPutImage problem in nxlib.

The FLTK blending does XGetImage() to read the background, which calls
GrReadArea (nxlib) in microwindows and the image returned is in the
wrong format.
XGetImage expects 4 byte format and the GrReadArea returns hardware
format, in my case 5:6:5 RGB (2 bytes per pixel).
There should be 2 unused bytes between every 2 data bytes.
For 5:6:5 RGB, it should be:
0000:RGB 0000:RGB ...
but is:
RGB:RGB RGB:RGB ...

This causes the data to be only half the size of the array and the
background is valid for the top half of the image and black for the
bottom.

I added a loop that spreads the array data in XGetImage() after the call
to GrReadArea and then it works.
This makes me believe that the XGetImage function does not work for
<=16bit resolutions.

The question are: 
Is there a conversion routine that does this?
Where the conversion should be done? (in XGetImage?)


The second problem is with XPutImage function in nxlib-0.45.
It does not draw pixels when foreground and background are zero (black).
This problem is similar to XDrawString which would not draw for the same
condition.
I already reported and fixed this problem.
This would be OK if the background was already black but in my case it
is not and the black pixels are simply not drawn (transparent).
I fixed it by changing the background color for this case but I think
there should be a better way to take care of this problem in XPutImage
and XDrawString.
Any suggestions?

Martin


-----Original Message-----
From: ####@####.#### ####@####.####
Sent: Saturday, October 21, 2006 7:52 AM
To: ####@####.####
Cc: Martin Kajdas
Subject: Re: Alpha blending problem


I have some more information.
The Alpha blending is done by the FLTK and not by the Microwindows.
Then, the FLTK calls the XputImage() to do the drawing with the blended
image.
The only problem with the image is that the blended pixels which should
be black are transparent and possibly other problems that I cannot see.
This appears to be one of those cases where the color conversion from
X11 to Microwindows colors (255 <-> 0) does not work.
I thought this was already fixed but there must be another case.

I believe that the black color is 0, what is the transparent color?
Any other suggestions where to look for this problem?

Martin

> XGetImage expects 4 byte format and the GrReadArea returns hardware
format, in my case 5:6:5 RGB (2 bytes per pixel).
> There should be 2 unused bytes between every 2 data bytes.
> For 5:6:5 RGB, it should be:
0000:RGB 0000:RGB ... but is: RGB:RGB RGB:RGB ...

Yes, this is definitely a problem with the image routines
in nxlib.  I had to guess the format of color images, I didn't
find it in the Xlib manual.  Do you happen to know where
to find the return image format for 24 and 32bpp?  It would
be nice to have this fixed for all formats.

> This makes me believe that the XGetImage function does not work for
<=16bit resolutions.

Likely true

> Is there a conversion routine that does this?
Where the conversion should be done? (in XGetImage?)

Another option would be to change the return format
parameter in GrReadArea, and always return 32bpp
0RGB data.  Then, the conversion could be applied
to convert to the Xlib required format (docs needed)
in one place only.




> The second problem is with XPutImage function in nxlib-0.45.
It does not draw pixels when foreground and background are zero (black).
This problem is similar to XDrawString which would not draw for the same
condition.
I already reported and fixed this problem.

Definitely a bug,  but your earlier fix was for text drawing
only, right?  I asked about the fix and couldn't get a fully
accurate description of why it worked.



> This would be OK if the background was already black but in my case it
is not and the black pixels are simply not drawn (transparent).
I fixed it by changing the background color for this case but I think
there should be a better way to take care of this problem in XPutImage
and XDrawString.

I don't think Xlib supports transparent drawing, so this is just
a bug in the image code.  XDrawString will have to be handled
seperately.


Regards,

Greg



I have some more information.
The Alpha blending is done by the FLTK and not by the Microwindows.
Then, the FLTK calls the XputImage() to do the drawing with the blended
image.
The only problem with the image is that the blended pixels which should
be black are transparent and possibly other problems that I cannot see.
This appears to be one of those cases where the color conversion from
X11 to Microwindows colors (255 <-> 0) does not work.
I thought this was already fixed but there must be another case.

I believe that the black color is 0, what is the transparent color?
Any other suggestions where to look for this problem?

Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: ####@####.####
For additional commands, e-mail: ####@####.####