LMD VCL - Glyph Transparency

Transparency source

Standard TImageLists

All image list component, including standard `TImageList `provides some sort of intrinsic transparency. For example:

The icon, shown above, can be imported into image list differently, and will have or have no transparent parts depending of transparent color, specified during importing.

First, let the component editor choose auto transparent color:

Second, let override the color:

As a result we'll get two different image list items with different transparent pixels, generated from the same image file. And the second item have no transparent pixels at all, so its magenta backgound should be pained as a part of image to the final destination canvas.

Note also, that transparent colors are not a property of image list items. Colors was used only during importing.

Imagelists with 32-bit color depth provide native support for alpha channel transparency. By default (which is important ot note), all importing 32-bit bitmaps are treated as transparency-enabled by the component editor.

In addition to the descripbed aspects, transparent pixels can be affected by `TImageList `component properties, like `BkColor `and `DrawingStyle`.

> So, the colclusion: `TImageList `provides intrinsic transparency, which depends of transparent color, specified during image importing, 32-bit color depth, and, `BkColor` and `DrawingStyle` properties.

TVirtualImageList

As well new virtual image lists can import 32-bit bitmaps, pngs, ect. So, such image lists provide complex (not quite understandable) intrinsic transparency, which we should respected.

TLMDImageList

LMD image list component provides `TLMDCustomImageList.TransparentColor` as "official way" to get information about item transparency. This is used in `LMDIMLTransparentColor` global function. 32-bit images are not supported currently.

Glyph properties

Since `TBitmap `type of `Glyph `properties provides no ways to customize transparency during image importing time (as opposed to `TImageList`), all 24-bit bitmaps should be treated as color-key transparent, while all 32-bit bitmaps should be treated as alpha-transparent.

Implementation details

LMD- Tools controls almost always draw initial graphics (from image list or a `Glyph `prroperty) onto the temporary bitmap buffer.

Image lists

In case of image list graphics source `LMDIMLItemBitmap `function is used.

For image lists with 32-bit color deptch we adjust destination bitmap pixel format to be also 32-bit, and alpha format to be defined.

For other (24-bit) image lists its hard if not impossible at all to deduct which transparency rules are really used. Moreover, `TCustomImageList.DoDraw` method is virtual, allowing descendants to do anything. So, in this case we have no better solution than to draw image list item into bitmap, prefilled with some exotic color, and then use this color as a transparent color key. I've declared the following global variable for this:

This way all intrinsic image list transparency, described above will be respected as much as possible.

For controls, which provide `TransparentColor` customization property, the property value is used to fill buffer bitmap instead of global value described above.

Glyph properties

As noted above, 32-bit bitmaps loaded into `Glyph` property are treated as alpha-enabled. However, we cannot set original bitmap `AlphaFormat` to `afDefined`, because this causes internal bitmap data to be premultiplied. And this is wrong, because published property data should be leaved unchanged for potential dfm (re)saving at design-time.

So, any Glyph property graphics have to be copied into some temporary buffer bitmaps, in which alpha support can be turned on. `TLMDGlyph` class caches and reuses such buffer bitmaps.

Other (24-bit) graphics uses standard `TBitmap.TrnsparentColor` feature to auto-detect transparent color, unless the control provides its own color property.

Internal Api

So, it seems that any kind of transparency can be represented with simple `TBitmap` object, and transfering additional parameters such as `TransparentColor` or `Mask` is not really required. However, for now, and for more explicit code, I've declared special `TLMFGlypTransp `record with some public methods for explicit configuration.

The record values are used as parameter values in `LMDDrawTextAndGlyph`, `LMDDrawTextAndGlyphExt` and `LMDBmpDrawExt` functions, which was modified to update transparency semantics. These function are now able to draw 32-bit bitmaps, as well, as color-key transparency bitmaps.

`LMDIMLItemBitmap` function was also modified to produce 32-bit bitmaps if required, and to support prefilling of 24-bit bitmaps with required color-key.

`LMDIMLTransparentColor` function (as has been mentioned above) was modified to report `LMDDefaultImageListTransparentColor` color as a transparent color for non-LMD image lists.

`TLMDGlyph` class was changed also. It does not use image lists to cache bitmaps anymore. Inidividual `TBitmap` objects are used instead. Both: color-key and alpha channel are supported.

Also, `TLMDGlyph` class got new `OnGetBitmap` event, which allow to grab the bitmap from other sources (such as image list or standard glyph from resources) leaving `Glyph` bitmap unchanged.

Controls

Controls, which provide several glyph sources, like `Glyph`, `ImageList`/`ImageIndex`, `GlyphKind` properties now implement mutual properties semantic, e.g. setting one of the properties will reset all others to default values. `TLMDGlyph.OnGetBitmap` is used internally.

`TransparentColor` and `GlyphTransparent` control properties are respected using `TLMFGlypTransp` record configuration methods. In extreme (wrong) case where image list item provides some transparent pixels and, at the same time, `GlyphTransparent` is set to `False`, the user will see `LMDDefaultImageListTransparentColor` backgound.

For 32-bit graphics `GlyphTransparent` properties are ignored.

Actions

Action images are now linked via `ImageList`/`ImageIndex` control's properties, as opposed to old `Glyph` way. Using image lists instead of `Glyph` bitmaps provides auto DPI csaling in case of virtual image lists.

In Delphi action only takes care of `ImageIndex` property, so, control's `ImageList` itself is not affected. I've adjusted this strategy to the following:

• if control's `ImageList` is nil, we link it from the corresponding action list.
• Linked `ImageList` can be overidden by the user to another `ImageList`. And, thus, become not linked anymore.

Linked properties are not stored in dfm.

Design-time editors

`TImageList` standard component editor poorly support 32-bit bitmaps. As well it wrongly import transparent png files. At the same time `TImageList` itself can support all of this stuff very well.

Another one mising feature - drag&drop image filles directly into the editor. From desktop or file explorer, as well as from special icons tools, like Pichon.

`Glyph` properties of `TBitmap` type allow to import 32-bit bitmaps correctly. But, custom property editor can also allow to load transparent png files directly into bitmap properties. As well, drag&drop support can be added.

> So, the idea - develop replacement for standard image list component editor and `TBitmap` property editor.

Font based image list

> We can create new font based image list to be used with Windows 10 Segoe Mdl2 Assets font.

Not very hard to implement. Will provide:

• Re-coloring on-the-fly (useful for VCL Styles scenario)
• DPI scaling, like virtual image list
• Clear type (sub-pixel anti-aliasing)
• XE2 support for our own use (in demos), since TVirtualImageList does not exist in XE2, so no DPI scaling of images is possible in XE2.
• Much simpler than SVG image list.