--- bill lam <[EMAIL PROTECTED]> wrote:

> Oleg Kobchenko wrote:
> > How about the single integer representation of color
> > and transparency?
> > 
> > Note: the same integer color+transparency could
> > be useful with gl commands, in particlar glpixels,
> > to provide compositing. While masking is possible
> > with off-screen images, gradual transparency would
> > allow nice blending of image edges with the backdrop.
> > 
> > Compositing of images is also possible in the off-screen,
> > but it requires color separation and integer-valued
> > arithmetic, which is very costly in J.
> > 
> 
> I agree that transparency should be supported if hardware or graphic library 
> of 
> frontend does. But will that be supported, or a zero value representing full 
> transparency or full opacity. This depends on the underlying graphic system 
> rather than J itself. IMO J should match as closely as possible with the 
> graphic 
> system to avoid costly computation. I prefer just leave the byte order and 
> transparency undefined by J itself but implementation dependent.  It should 
> be 
> the responsibility of the application to query and take appropriate data 
> format.
> 
> That means interpretation of data passed to glpixels cmd may be depended on 
> endian. I think that this is necessary albeit unfortunate, because speed is 
> the 
> most important factor in rendering graphics.

Treating the RGB order in integer for glpixels and glqpixels is already
supported in endian-neutral way: it works for both Windows FE and Java
on big-endian machines. So there is no reason to degrade that feature
if there is special support for it.

In Java sRGB color is defined in endian-neutral way:

Color(int rgb) 
   Creates an opaque sRGB color with the specified combined RGB value 
consisting of the red component in bits 16-23, the green component in 
bits 8-15, and the blue component in bits 0-7.
   http://java.sun.com/j2se/1.4.2/docs/api/java/awt/Color.html

There are two open questions:
 - extend the support for integer RGB for glrgb. It is simpler
   and more efficient to handle one integer values than three.

 - use the high byte of ARGB integer color as transparency value
   to allow compositing by applying multiple glpixels on the same
   area to achive effects such as masking, shadows, highlights,
   plastic and glassy buttons effects, etc.

In Java the high byte is treated as Alpha, i.e. opacity. However,
it not compatible with RGB-only images, like BMP and JPEG: they
return 0 for the high byte. Because they are opaque, it is natural
to treat the high byte as transparency.


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to