Robert Roessler: > So this *might* take the form of "parallel" color-setting calls, with > the original form for "classic" rgb colors, and a new form for argb?
No, separate alpha calls as there needs to be a way to specify alpha / no alpha as well as 8 bits of alpha and 24 bits of RGB so its more than 32 bits. Neither of the platforms in the main distribution support alpha on most graphics calls so alpha has to be added with quite a bit of code: the SinkWorld code for translucent polygons is more complex, slower and more fragile than the Scintilla code which only does rectangles with corners. Alpha will be implemented in small pieces over time. > Once (and if) you decide that the API will get a number of new calls, > then it could be slick to do it this way... why? Not only are you > avoiding the confusing nastiness of making a bunch of new "modes" > visible in the user's model of the API, new parallel color-setting > calls could be viewed as steps in a migration to a new[er] API. I think users may want separate control over which features use alpha. > Finally (and this may or may not be a good idea), if this stuff ends > up being costly on lower-end/embedded client H/W, a global performance > vs looks setting could be introduced... shudder. Alpha is also unavailable on various platforms including GTK+ 1.x and early versions of Windows as evidenced in the code by the dynamic loading of Msimg32.DLL. Neil _______________________________________________ Scintilla-interest mailing list [email protected] http://mailman.lyra.org/mailman/listinfo/scintilla-interest
