Hi,

All LCL colors seem to be defined in the format TColor($BBGGRR) - all without the Alpha channel information. Does TColor support the Alpha channel, and if it does, will it it be applied everywhere or all supported widgetsets?

If TColor does support the Alpha channel, in which format should the TColor be defined?

TColor($AABBGGRR)
or
TColor($BBGGRRAA)

Inconsistency noted:
--------------------
Also there is an inconsistency at least with LCL-GTK2's Color Select dialog. If I type the hex color Red in the Color Select Dialog, the format must be typed as FF0000 (RRGGBB), but when I code the color Red in Lazarus, it must be typed as 0000FF (BBGGRR). I guess because of the LCL "native widget set" idea, there is nothing that can be done about this.

Regards,
Graeme

Hi,
 
on one hand,
 
TColor = TGraphicsColor
and
TGraphicsColor = -$7FFFFFFF-1..$7FFFFFFF;
 
on the other hand, there are defined colors like
 
clNone    = TColor($1FFFFFFF);
clDefault = TColor($20000000);
 
So I'm also curious if its possible *somehow*.
 
Vojtěch

Hi, All LCL colors seem to be defined in the format TColor($BBGGRR) - all without the Alpha channel information.

Correct.

Does TColor support the Alpha channel,

No.
The hi byte is used for system colors. Under Delphi also for palette. The idea is to use the FPColor property for alpha, but that is not implemented yet by the LCL interfaces. Hmm, I wonder how hard it would be...

Usually I use the RGBToColor function, so I only see RGB.

Mattias

Mattias Gaertner wrote

The idea is to use the FPColor property for alpha, but that is not implemented yet by the LCL interfaces. Hmm, I wonder how hard it would be...

Speaking from my experince, nearly impossible :(

It doesn't really make sense for me anyway because windows with handles (TWinControl descendants) don't support alpha-transparency on Windows.

For me it would be just a source of bugs and incomplete WS-dependent implementations.

Ondrej

Mattias Gaertner wrote

> Does TColor support the Alpha channel, No.

Wow, that's surprising.

The idea is to use the FPColor property for alpha, but that is not implemented yet by the LCL interfaces. Hmm, I wonder how hard it would be...

Does that also mean every widget in LCL will have a Color and FPColor property?

  eg:
    Label1.Color := ....;
    Label1.FPColor := ....;

That would be very messy!

Usually I use the RGBToColor function, so I only see RGB.

Ah, thanks for that tip.

Regards,
Graeme

First of all setting Pen.FPColor sets Pen.Color and vice versus, so you only set one.
And second I doubt that alpha is useful for all native widgets.

Mattias

In this case maybe this property pair would be more appropriate (?):

Color := ...;
Alpha := ...; // property Alpha: Byte

Ondrej

A property "Alpha" sounds like setting the alpha of the whole control.

Also FPColor contains 16bit channels.

Mattias

Aah, I see now what you mean. Then ColorAlpha :)

Ondrej

Or:
"
Alpha := ...; // property Alpha: TColor
"
for alpha per colour channel. MSEgui works this way with pixmap opacity. In case of pixmaps with simple alpha channel the 8 bit alpha value is (R+G+B) div 3.
In MSEgui mask- and color-data of TMaskedBitmap are separate pixmaps with own canvas.

Martin

Ondrej Pokorny wrote

Aah, I see now what you mean. Then ColorAlpha :)

An then you start getting the contradicting properties.

For example:

  Label1.Color := clRed;
  Label1.ColorAlpha := 170;
  Label1.Transparent := True;

or, what to do if Label1.Transparent = False?

Or does in now mean the TLabel.Transparent property is going to be deprecated because ColorAlpha will replace its job. Oh, but then we have the Delphi-compatibility issues to deal with too. :-(

Regards,
Graeme

In that case I would make it a record type with RedAlpha, GreenAlpha and BlueAlpha: Byte. Why?, Because TColor's range is way to large, with most of the acceptable values being meaningless.

Regards,
Graeme

Using TColor has the advantage that the same mechanism of RGB-lookup of "logical" colours as with normal TColor values can be used. TColor with the MSB = 0 is a special case where the lower bytes contain the RGB values. Simple and efficient.
In MSEgui the MSB defines the kind of the logical color value, "functional" (cl_invalid,cl_default..), "mapped" (cl_dkshadow,cl_shadow...), "named RGB" (cl_black, cl_dkgray...) and "user".

Martin

Is there a need for alpha *everywhere* a color is used? From my experience, i've only really needed alpha for TCanvas (so i can draw, e.g. translucent rectangles). I don't think there is a need to add more baggage in controls by introducing yet another mostly redundant FPColor property. Controls that need color with alpha could just provide a ColorAlpha property (for Color property - if a Color property is named Foreground or SecondaryColor then the alpha would be ForegroundAlpha or SecondaryColorAlpha).

If one doesn't care about compatibility with Delphi, a Color: TFPColor property could be used and Lazarus be made (if it doesn't already) to handle TFPColor similarly to TColor but with a custom dialog that can edit the alpha.

For TCanvas, a TFPColor behind the scenes that is mapped to both TFPColor and TColor properties on access should be enough. Yes, it is redundant, but since most Canvas use is done via code (instead of a visual property editor), i'd say that being able to access RGBA as a single value instead of a value pair is cleaner.

On Mon, Sep 26, 2016 at 4:52 PM, Martin Schreiber via Lazarus <

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20160926/5e8007a3/attachment.html>

Kostas Michalopoulos wrote

Is there a need for alpha *everywhere* a color is used?

So how would functions that take TColor parameters work? For example, drawing a gradient with increasing Alpha value, say via a TCanvas.GradientFill() call. In the case of GradientFill() it has a Start/Stop TColor parameter. Also other functions like DrawGradientWindow() etc. So for each such cases, new overloaded versions will be implemented, replacing TColor with TFPColor?

Regards,
Graeme

Yes, overloaded versions that take both TColor and TFPColor (with the former calling the latter with conversion function) should be the best approach both to preserve backwards compatibility (for existing code) and consistency (for any new function).

On Mon, Sep 26, 2016 at 6:41 PM, Graeme Geldenhuys via Lazarus <

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20160927/d82acfca/attachment-0001.html>