Neil Hodgson wrote:
A problem with including alpha in each colour is that the high byte has been zero up until now which, as an alpha, is completely transparent and would be invisible. Current containers would be cross. The alpha could be inverted from common usage, but rendering through alpha based code may display differently and will be slower. Therefore, my preference is for an alpha of 0 to mean: use current opaque drawing.
That makes sense... but where are you going with this? I can't really tell if you are saying that you will *not* have "4-tuples" with alpha values at all because of incompatibility with the current implementation, or *will* use 4-tuples with alphas - but special-case the zero values to be the inverse of what would be usually expected.
Actually, looking at that last bit, it looks silly enough that you probably do not mean that. ;)
Like I said, leaving colors at 24 bits is fine with me (vis-a-vis the 32-bit versions of OCaml - which have 31-bit ints).
While I know you do not like gratuitously inflating the Scintilla API, there is always the possibility of defining parallel calls using the "new" color layout. This also works in nicely with bindings for languages that are strongly typed - the new color+alpha values could be represented by a new/different type to use with the new calls - if one cared about such things.
Robert Roessler [EMAIL PROTECTED] http://www.rftp.com _______________________________________________ Scintilla-interest mailing list [email protected] http://mailman.lyra.org/mailman/listinfo/scintilla-interest
