nanogui: Re: Qusetion abuot Nano-X alpha blending
Subject:
Re: [nanogui] Re: Qusetion abuot Nano-X alpha blending
From:
"Greg Haerr" ####@####.####
Date:
11 Jul 2005 17:35:10 +0100
Message-Id: <528301c58636$6917ca90$6401a8c0@winXP>
> I prefer that GrNewAlpha will generate a Pixmap with a flags called 'need
alpha blending'
> Therefore, GrCopyArea can using this flags to draw image alpha blending or
not.
> Such that, FLTK or xlib calling the XCopyArea will call GrCopyArea and it
> will automatically determinated draw the image in which mode.
The current implementation doesn't require any special handling
for alpha blending; if the pixmap is ARGB format (and the framebuffer
supports hardware alpha), then it just works. No need for GrNewAlpha,
and no need for special GrCopyArea handling/flags, which as you
are saying aren't coded into the underchassis of FLTK/FLNX.
With Thomas' patch applied, we will support software alpha-blending
for images in ARGB format. What we need is code in engine.c::GdBlit()
for the similar case to handle ARGB blits when the framebuffer
doesn't support hardware alpha.
> it give FLTK or xlib program a graphic engine level alpha blending feature
althought it is not a standard way to implement alpha rednering in Xlib API.
> Notes: FLTK call fl_create_offscreen -> XCreatePixmap And
fl_copy_offscreen
--> XCopyArea to perform a RGB image drawing.
Does anybody want to comment on how Xlib handles alpha rendering,
my understanding its through the Xext mechanism, rather than basic
functions, is this the case?
It is very convenient to not have to handle alpha blending in a special
way, thus requiring rewriting widget set internals to handle PNG
files with alpha, for example.
Regards,.
Greg
> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
>
