nanogui: More on Image handeling and optimizations
Subject:
Re: More on Image handeling and optimizations
From:
"Greg Haerr" ####@####.####
Date:
26 Jan 2000 17:48:24 -0000
Message-Id: <04b301bf6824$18474ae0$15320cd0@gregh>
: Notice that I have implemented a 'driver_gc_t' low
: level graphics context that works very well in the
: low level Area handeling code and the interface to
: it. It helps keep the low level drivers both
: elegant and fast (only a pointer gets passed around
: inside and into the driver).
I'll take a look at your patch and hopefully add
most of it.
: Do you unpack, multiply, add and pack for each pixel in
: the 16 and 32 bit cases? How fast is this method?
: I rejected this method without even testing it because
: I figured it would be too slow...
:
Yes, for each R, G, B component, theres a unpack,
subtract, multiply, shift, add and pack:
dest = (source-dest)*alpha/256+dest;
for each color. The above is equivalent to the
std alpha blending algorithm:
dest = src * alpha + (1 - alpha) * dest;
Where alpha varies from 0 to 1. In implementation,
alpha varies from 0 to 255.
: OK, my code is ugly as it adds another pointer to memory
: so the 16-bit image data are separate from an 8-bit
: alpha map. This will requre an API change, which I have
: not figured out how to do yet. One possible and
: attractive solution is to make new Gd* and Gr*
: functions.
We will need functions for per-pixel blending and constant
blending. In addition, we might want to have separate
alpha channel blending where the alpha isn't bound
to the source bitmap. (I guess you need it with 16bpp
images. Why don't you just switch to 24?)
Regards,
Greg
