Jon M. Taylor writes:
> > I find your "Alpha" blending types rather strange, (sc | dc),
> > (sc & dc), etc... Quite different to what I expected, which is
> > basically the OpenGL style:
> >
> > Rdest = Rsrc * Asrc + Rdest * (1 - Asrc)
> > Gdest = Gsrc * Asrc + Gdest * (1 - Asrc)
> > Bdest = Bsrc * Asrc + Bdest * (1 - Asrc)
>
> "sc | dc" does not mean a bitwise OR between two 32-bit ggiPixel
> values. It is shorthand for the individual R-G-B logical Sorry, that is
> a bit confusing.
The code does this too (e.g. workingpixel |= destpixel), that's why I
thought they were C-like bitwise ops.
So what do the "|" and "&" operators mean in your blend descriptions ?
> > corresponding to BlendFunc(SRC_ALPHA, ONE_MINUS_SRC_ALPHA). (Those
> > formulas assume values between 0 and 1).
>
> Well, I _could_ do this as well. Problem is, it forces alpha
> representations into float[0..1] format,
Use floats ? No I wasn't suggesting that, using values between 0-255
for alpha is sufficient and simple to implement:
Rdest = (Rsrc * (1+Asrc) + Rdest * (256-Asrc)) >> 8;
Gdest = (Gsrc * (1+Asrc) + Gdest * (256-Asrc)) >> 8;
Bdest = (Bsrc * (1+Asrc) + Bdest * (256-Asrc)) >> 8;
> > It seems that your XMI is becoming less and less like the "real" XMI.
>
> Yes, although I am making an effort to minimize this.
>
> > Removing miPaintedSet from the API would tip the barrel, making it
> > pretty hard to keep calling it "XMI" in my opinion.
>
> Well, there would still be quite a lot of stuff that would be the
> same, too.
Being "very similiar" doesn't cut it IMHO, either some XMI application
can be ported with minimal changes or it can't. Removing miPaintedSet
would make it hard to port any XMI apps that relied on them.
(I'm assuming that there really are XMI applications out there, and
the potential for more to appear).
Another thought occurs to me: porting GGI XMI apps to the other one.
Your new additions (like the miBlend stuff) would make that hard too
if the application relied on them.
I doubt anyone would ever want to do this, but the point is: you are
not creating an implementation of the "XMI API", but creating a new
(better) API which is different (i.e. incompatible to some degree),
and therefore it should be called something different.
> > That's not a
> > criticism, I think it would be cool to take a big axe to the API and
> > make something much cleaner and more GGI-like (e.g. miPoint and
> > miRectangle are a bit painful unless doing lots of them).
> ^^^^^^^^^^^^^^^^^^
> That's usually what you use them for, yes. Batching primitives
> like that is something that LibGGI doesn't do, and since it can be
> accelerated in many cases there's justification for leaving them in the
> API.
Fair enough. I wasn't suggesting remove them, but maybe augment the
existing calls with single-minded ones, like instead of:
miRectangle rect;
rect.x = x;
rect.y = y;
rect.width = w;
rect.height = h;
miFillRectangles(vis, paintedSet, pGC, 1, &rect);
allow this:
miFillRectangle(vis, paintedSet, pGC, x, y, w, h);
Cheers,
__
\/ Andrew Apted <[EMAIL PROTECTED]>
