nanogui: Re: Qusetion abuot Nano-X alpha blending
Subject:
Re: [nanogui] Re: Qusetion abuot Nano-X alpha blending
From:
"Greg Haerr" ####@####.####
Date:
10 Jul 2005 22:19:03 +0100
Message-Id: <4ea801c58594$ead886c0$6401a8c0@winXP>
I wanted to have a discussion on Alex's alpha channel
support, to determine which portions might be useful
to consider looking at for retrofitting... comments follow
: GrNewAlpha() is one of the functions in the microwin-aph alpha
: channel support.
: It worked by treating alpha channels as a special type of offscreen
: drawing area.
Originally, I rejected this patch because of the new special
type of offscreen drawing. The ARGB approach, which
didn't require special offscreen pixmaps, but rather just
alpha-coded 32bpp pixmaps/windows, was implemented
instead. I didn't think it was necessary to have to think
of an alpha channel as any different than standard image data.
: You could either construct one on the fly by using
: ordinary drawing operations on a blank alpha channel (created with
: GrNewAlpha()), or you could load one from an image file (PNG or
: transparent gif) and then potentially modify it by drawing to it.
In the current model, the image decoders will (or could easily)
include the alpha information in the current image, as ARGB.
: The
: actual blending operations were performed using the GrCopyAreaAlpha()
: function which was the same as GrCopyArea() except it also took an
: alpha channel ID and a flag specifying which type of blending
: operation to perform.
The GrCopyArea as a "op" flag passed as the last parameter,
which allows specifying operation type without having
to have an additional API entrypoint.
: I think anyone interested in having decent
: alpha channel support in Microwindows should take a look at the code
: in microwin-aph and consider whether it would be worth porting it
: forward. The hardest part was adding the alpha blending support to
: the low level drivers (it's all software based, which unfortunately
: means it needs a fairly fast CPU to get decent realtime effects).
Thomas' patch implements alpha channel blending at the
engine level (slow, but very portable) for systems that don't
have hardware alpha framebuffers. I plan on adding his patch,
as I mentioned after sorting out the also-included greyscale
stuff for no-palette images.
This patch is certainly slower, but a flag could be added so that
if the driver supported software alpha support in the Blit
or DrawArea routine, then it would be called instead. This
still has issues since the current implemention is in GdDrawImage
only, not in the GdBlit routine.
: If
: you must reinvent the wheel, think hard before discarding the ability
: to create/load alpha channels into a pixmap-like object and perform
: drawing operations on them as if they were pixmaps:
Why introduce a new drawing type, why not have any pixmap
serve as a potential alpha channel? In this way things are more
general, and special code doesn't have to be written for
alpha channel handling.
: the range of cool
: visual effects you can achieve by drawing on alpha channels is
: staggering (see Nano-breaker for some fairly simple examples).
Agreed
Regards,
Greg
