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.
--
regards,
bill
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
