Consistent Alpha channel support

[Little John]

The current PB version 5.42 LTS does handle colors (namely the Alpha channel) not consistently.
For instance, the CanvasGadget is a 24 bit drawing output. It has no alpha channel. The parameter BackColor for CreateImage() is also a 24 bit value, i.e. it must not have an Alpha channel. On the other hand, for the new VectorDrawing library all colors must be 32 bit values.

My wish is, that all functions (and predefined constants) in PB that deal with colors would have Alpha channel support.

[netmaestro]

The CanvasGadget is different from the ImageGadget in that it doesn't support an alpha channel for blending with the window color. Take my word for it, this is a good thing. The ImageGadget, when it is hosting a 32bit image, will flicker badly if the contents change too quickly. Poor-to-bad-to-rotten for any kind of animation. On Windows, (the only OS I can speak about with any knowledge at all) it is a heavily subclassed static control that has been trained to blend the alpha channel with the window background if it finds itself hosting an image of 32 bits depth. The Windows Static Control was never intended for this kind of implementation. As a result, the PureBasic ImageGadget, when it's hosting a 32bit image and blending the found alpha channel, is what we programmers refer to as a "Major Hack." Major with a capital 'M'. That it works at all is a tribute to the cleverness of Timo Harter, who rose to the challenge and, against all odds, made it work in the 2dDrawing and image overhaul that took place a few years ago. Should this behavior be extended to the CanvasGadget? My vote is no, not in a million years. You can make a nice animation on the CanvasGadget now, one that won't flicker ever. Don't ask for something that would f**k that up. Please. There are boundaries in our business. Respect them and thrive. Ignore them and never experience the pleasure of a peaceful night's sleep again.

[walbus]

Not realy, or ?