Micha Nelissen wrote

Big *sigh*. Turns out that StretchBlt is implemented with transparency support in gtk. Really, these extensions need to be documented in TInterfaceObject. How else can we EVER expect to get other (like qt) interfaces working? The win32 api is at least documented in msdn.

oh. hum. this is not an extension to the routine.

that is because of pixmaps. pixmaps natively have a mask, bi-level bitmask. Win32 on the other hand uses bitmap which has no such thing. Thus native format on windows has no need for transparency in the stretch routine, which is why in Delphi they have to have special functions etc to handle it.

AKA this is because in gtk+ the alpha support is in the backend level, in win32 it must be on the LCL/App level, or with a special function in the backend.

This isn't a matter of what the function does so much as what the format is. If pixmap didn't natively support alpha via a bitmask, then the routine wouldn't handle it. :)

Andrew

Hi, How does bitmap transparency work in the lcl?

First of all: it is not completely implemented. (Same with palettes).

I noticed that recently most of the buttons in the IDE aren't transparent anymore on win32. Some have a black background, some gray (these look transparent) and others are white.

See bitmap.inc ReadStream.
The IDE icons are in xpm format, so they are converted to handles with CreatePixmapIndirect

The returned handle is up to the interface. For the gtk-interface it is an internal GDI object, which stores the image, the mask and some other info.

Mattias

I wonder if this is the case.
What might be the case is that it erroneously uses StretchBlt where it should have been using TransparentStretchBlt

If one takes the win32api as api (StretchBlt), then from a win32 POV it seems an extension on which there is a dependency.

As Andrew said, it is *not* an extention. It is native behaviour of the image. Pixmaps have a transparency. So drawing an image with transparency (Pixmap) will result in an image with transparency. Drawing an image without transparency (win32 Bitmap) will result in an image without transparency

Said another way, if StretchBlt does not support transparency, which it does not for win32, the LCL does not work correctly. Which is what I am experiencing.

ATM I don't know where,what and how, but I assume that TransparentStretchBlt should have been used.

Do you have any tips how to make a transparency mask so I can implement the necessary behaviour?

Look at the implementation of TransparentStretchBlt

But, don't modify the interface StretchBlt function to draw transparent. It should *not* modify the image.

Marc

Hi,

How does bitmap transparency work in the lcl? I noticed that recently most of the buttons in the IDE aren't transparent anymore on win32. Some have a black background, some gray (these look transparent) and others are white.

Info appreciated,

Micha.

Yes, but the LCL depends on this 'native' pixmap support for transparency. If one takes the win32api as api (StretchBlt), then from a win32 POV it seems an extension on which there is a dependency. Said another way, if StretchBlt does not support transparency, which it does not for win32, the LCL does not work correctly. Which is what I am experiencing.

Do you have any tips how to make a transparency mask so I can implement the necessary behaviour?

Micha.

Big *sigh*. Turns out that StretchBlt is implemented with transparency support in gtk. Really, these extensions need to be documented in TInterfaceObject. How else can we EVER expect to get other (like qt) interfaces working? The win32 api is at least documented in msdn.

So transparency has never worked for win32, but it just seemed that way because the pictures had gray background some weeks ago?

Micha.

Only in a few cases. And they can be changed easily. In fact, they are leftovers from days whithout choice.

Some general notes:
Eventually we will switch to fpImage. This means the LCL won't need CreatePixmapIndirect anymore. fpImage requires, that the win32 intf supports the 5 RawImage functions.
Micha, can you implement them?

I wonder if this is the case. What might be the case is that it erroneously uses StretchBlt where it should have been using TransparentStretchBlt

yep

?

Mattias

Ok, so what fields need to be filled in GetDescriptionFromDevice?

The 'compatible' in CreateCompatibleBitmap means compatible to some DC. With the current 5 fpimage functions, this function cannot be used, because I don't know what DC to create a compatible bitmap to.

What I was trying to say is: in the example at the top of the intfgraphics unit, there is the sequence (GetDescriptionFromDevice, CreateBitmap); my question is: is GetDescriptionFromDevice in any other context? Ie. is it used for anything else than calling CreateBitmap later on? Otherwise we could remove the GetDescriptionFromDevice and replace it with CreateBitmapCompatibleToDevice, as you suggested later in this post.

Regards,

Micha.

Yes. Feel free to change them.

BTW: HBITMAP's don't know anything about their palette in win32. I know palettes are not supported yet, but how should I work with it? Ie. I must fill the ImageDescription with something.

Hmm. What kind of information is available for a bitmap under win32?

Mattias

See winapih.inc, search for RawImage.
See graphtype.pp for the RawImage format.
intfgraphics.pas contains the TLazIntfImage which uses the 5 functions.

I suggest you start with
GetBitmapRawImageDescription
then
GetRawImageFromBitmap
then
CreateBitmapFromRawImage
then the other two.

The interface does not need to convert the pixels itself. This is done by TLazIntfImage.

Some notes:
The RawImage format describes uncompressed images in memory. For example: width, height, bits per pixel, alignment, ... . TLazIntfImage is able to convert such images. The fpImage color format is a subset of the RawImage format, hence TLazIntfImage is also able to convert between fpImage formats and any internal LCL interface format (gtk/X, win32 bmp). Because it uses the internal interface format, it is quite fast. For instance, the XPM reader written in pascal is several times faster than the gtk c code.

Mattias

I have been looking, but I can't find it in the archives / code: what functions do I need to implement?

Micha.

I guess, you mean the right thing.
GetDescriptionFromDevice should return only a RawImage description. No width, no height. Just the information about color depth, bits per pixel, ... . No real data. This information is used to calculate the needed memory and to know, how to set pixels.

Sounds like what we want. With the information in the RawImage description the data created already matches the color format. The interface only needs to setup the header.
The idea is to implement "CreateCompatibleBitmap" in a platform independent way.
Under win32 afaik you would normally use CreateCompatibleBitmap to create a bitmap. Then you load an image stream and set the pixels according to the color format. Under gtk you can also create a compatible image, but you can't set the pixels easily.
Under the LCL you can use GetDescriptionFromDevice. Then TLazIntfImage can create a compatible thing and fpmage can load an image. Then CreateBitmapFromRawImage creates the real handle and win32/gtk does not need to convert the pixels.

1. Every interface has some high level functions to do several steps at once. But they differ. What we need are functions, that work everywhere fast.

2. fpImage and TLazIntfImage can be used for much more, than "just" gui images.
Of course we can add some more RawImage functions, like creating a DC compatible bitmap, mask and RawImage description in one function. But the 5 base functions are needed anyway.

Mattias

A difficult way to say that if an image supports transparency it will be drawn transparent, if not, it won't be drawn transparent. :-)

Marc

Is GetDescriptionFromDevice only used to create a device compatible bitmap? If so, this can be done in win32 via CreateCompatibleBitmap. Retrieving all information requested by TRawImageDescription from a device context is very tedious, requires handling several cases (because in win32 objective a DC is a 'stateless' something to be drawn to).

Second reason is that the following lcl call CreateBitmapFromRawImage will use CreateBitmap which is not recommended by the win32 docs for most bitmaps:

---
While the CreateBitmap function can be used to create color bitmaps, for performance reasons applications should use CreateBitmap to create monochrome bitmaps and CreateCompatibleBitmap to create color bitmaps. When a color bitmap returned from CreateBitmap is selected into a device context, Windows must ensure that the bitmap matches the format of the device context it is being selected into. Since CreateCompatibleBitmap takes a device context, it returns a bitmap that has the same format as the specified device context. Because of this, subsequent calls to SelectObject are faster than with a color bitmap returned from CreateBitmap. ---

I don't know what the exact performance penalty is, but if it's even in the docs...

I am just asking because if you're _only_ after a call to CreateCompatibleBitmap, (not using device info like height, width) there is a much easier way.

Micha.

function GetRawImageFromBitmap(SrcBitmap, SrcMaskBitmap: HDC; const SrcRect: TRect; var NewRawImage: TRawImage): boolean; {$IFDEF IF_BASE_MEMBER}virtual;{$ENDIF}

Shouldn't those HDC's be HBITMAP's?

BTW: HBITMAP's don't know anything about their palette in win32. I know palettes are not supported yet, but how should I work with it? Ie. I must fill the ImageDescription with something.

Regards,

Micha.

It's even worse. When no DC is available to create a compatible bitmap with, CreateBitmap has to be used, we knew this. But now I found this on the internet:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=OsQ0iiDP%24GA.236%40cppssbbsa04&rnum=3&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26q%3Dwin32%2Bcreatebitmap%2Bmemory%26btnG%3DGoogle%2BSearch

---
Don't use CreateBitmap, use CreateDIBitmap or CreateCompatibleBitmap. CreateDIBitmap & CreateCompatibleBitmap both will create a bitmap that is guaranteed to be compatible (ie can be blitted to) with the screen. In addition, CreateDIBitmap takes a pointer to a device independent bitmap (ie the data contained within a .bmp file).

CreateBitmap on the other hand will create the bitmap you specify, but if the cPlanes and cBitsPerPel settings do not match the current display settings the bitmap can not be blitted to the display. ---

So it's not even guaranteed to work :(. FYI: CreateDIBitmap, CreateCompatibleBitmap both need a DC.

Micha.

Winapi function GetObject returns a BITMAP info structure containing:

bmType

Specifies the bitmap type. This member must be zero.

bmWidth

Specifies the width, in pixels, of the bitmap. The width must be greater than zero.

bmHeight

Specifies the height, in pixels, of the bitmap. The height must be greater than zero.

bmWidthBytes

Specifies the number of bytes in each scan line. This value must be divisible by 2, because Windows assumes that the bit values of a bitmap form an array that is word aligned.

bmPlanes

Specifies the count of color planes.

bmBitsPixel

Specifies the number of bits required to indicate the color of a pixel.

bmBits

Points to the location of the bit values for the bitmap. The bmBits member must be a long pointer to an array of character (1-byte) values.

----

I think I can fill the RawImageDesc fields except palette, and I don't know what to do with RedPrec, RedShift, etc..

Micha.

Agreed, but when you have the right number of bits, it's not so bad anymore, right?

I was not completely correct indeed. The DIBSECTION contains a BITMAPINFOHEADER. BITMAPINFO also contains the BITMAPINFOHEADER. If the BITMAPINFOHEADER.biCompression is BI_BITFIELDS, then and only then does BITMAPINFO.

Yes, but they are reading from disk. An in-memory bitmap, ie an HBITMAP handle, is different.

Ah I think found something finally:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=36B74D1B.E74A1F2A%40spamsucksaros.net&rnum=2&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26q%3DHBITMAP%2BBITMAPINFO%26sa%3DN%26tab%3Dwg http://www.users.cts.com/sd/m/menright/display.html http://support.microsoft.com/default.aspx?scid=kb;en-us;195829

It does not by default :(. The BITMAPINFO structure only suggests what 'defaults' are supported by windows 95.

Micha.

Ok. So, under win32 it seems, it is up to the user to keep book of the format of a DC/bitmap. But this data is win32 specific, so the LCL user can't do it. It must be done, by the win32 intf. Right?

Hardly believable.
Can this BITMAPINFO only retrieved from bitmaps or can you create a bitmap fom any device and get a BTMAPINFO? And with this, get the color format from any DC?

I think that's the reason why in delphi there is a pfDevice for TPixelFormat. Any tips? Shall I return a default color format in the raw image?

Yes. I guess, at least the screen resolution can be retrieved, can't it?

Mattias

Micha Nelissen wrote

I was not completely correct indeed. The DIBSECTION contains a BITMAPINFOHEADER. BITMAPINFO also contains the BITMAPINFOHEADER. If the BITMAPINFOHEADER.biCompression is BI_BITFIELDS, then and only then does BITMAPINFO

contain the {red,green,blue}{shift,prec} via three DWORD masks.

Micha.

Yes. But every conversion reduces the quality, so we should try to find the current format.

AFAIK the INFOHEADER does. See for example
http://astronomy.swin.edu.au/~pbourke/dataformats/bmp/.

I guess, win32 also defines, what bits are the red, green and blue?

Mattias

Aaah, that's why I didn't find it :). I assume it needs to be ported still?

Regards,

Micha.

Sorry for the massive quote :(.

Micha.

Where is this function defined? I have searched all over the place, but I can't find it. Only reference is in htmllite/litegif2.pas or something alike. But no definition.

Micha.

Sorry I keep nagging about this subject, but:
1) there is one function not needing a DC to create a bitmap, 'CreateBitmap'. It is not possible to retrieve color format of this bitmap. Even a google search did not turn up anything on the color format subject. I guess, nobody uses it.
2) the functions that do have information on color format also need a DC. You create a device independant bitmap with CreateDIBSection, and a device dependant one with CreateDIBitmap. Long live the winapi, logic is nowhere to be found it seems! The names are very unlogical.
3) there is no function to retrieve the color format of a device. One can only guess at it, based on BITMAPINFO structure help. That's because the winapi support converting the color formats on the fly. For example, using CreateDIBitmap, you specify the color format your source bitmap is in, and the winapi will convert it to the color format of the target device. It seems logical that one would be able to retrieve the color format of the device for fast rendering and stuff, but it just seems impossible. I think that's the reason why in delphi there is a pfDevice for TPixelFormat.

Any tips? Shall I return a default color format in the raw image?

Regards,

Micha.

Ok, in my recent commit I have implemented it except for the RedPrec and shift etc.

If the win32 intf needs to create a bitmap to get the needed information, it can create a small bitmap 1x1 and release it instantly.

Ok. I'll come up with something.

CreateBitmapCompatibleToBitmap? Nice challenge... :). Ah, there is a CreateBitmapIndirect too. It should be doable.

Regards,

Micha.

Let me first say: the color format I mean is the RRGGBBAA and how bits each take.

Yes. But the winapi can convert between color formats automatically. You give the win32 interface a color format, and it can pass it on to the winapi for processing.

The BITMAPINFO is contained with a DIBSECTION. The DIBSECTION can only be retrieved for device independant bitmaps, that means, bitmaps created by CreateDIBSection. No other function returns a BITMAPINFO structure.

The BITMAP structure can always be retrieved from any bitmap. But it doesn't contain the information to fill in {red,blue,green}{shift,prec}.

Creating a DIB section isn't of much use, if you ask me, because that's already what the rawimage is.

I am able to get the color depth and bits per pixel used, eg. 16, 24, 32 bits.

Regards,

Micha.

I think I can fill the RawImageDesc fields except palette, and I don't know what to do with RedPrec, RedShift, etc..

You need to find out the color format of the device/bitmap for this.

Example:
32 bits per pixel, 8 bit for red, 8 for green, 8 for blue, 8 bit for nothing.
Let assume a pixel has the following double word: $RRGGBB00

Depth = 24
BitsPerPixel = 32
RedPrec = 8
RedShift = 24
GreenPrec = 8
GreenShift = 16
BluePrec = 8
BlueShift = 8

Mattias

+ From: Micha Nelissen
+ Sent: donderdag 13 november 2003 11:02
+
+ Marc Weustink wrote:
+
+ > + From: Micha Nelissen
+ > + Sent: donderdag 13 november 2003 8:24
+ > +
+ > + Marc Weustink wrote:
+ > +
+ > + > At 17:59 8-11-2003, Micha Nelissen wrote:
+ > + >
+ > + >> Do you have any tips how to make a transparency mask so I can
+ > + >> implement the necessary behaviour?
+ > + >
+ > + > Look at the implementation of TransparentStretchBlt
+ > +
+ > + Where is this function defined? I have searched all over
+ the place, but
+ > + I can't find it. Only reference is in htmllite/litegif2.pas or
+ > + something alike. But no definition.
+ >
+ > It is part of the delphi source, defined in the graphics unit. +
+ Aaah, that's why I didn't find it :).

:)

+ I assume it needs to be ported still?

I think so

Marc

For the default, simply use FillChar(,0);.

Set all except the -

    Format: TRawImageColorFormat;
    HasPalette: boolean;
    Depth: cardinal;
-   Width: cardinal;
-   Height: cardinal;
-   PaletteColorCount: integer;
    ByteOrder: TRawImageByteOrder;
    LineOrder: TRawImageLineOrder;
-   ColorCount: cardinal;
    BitsPerPixel: cardinal;
    LineEnd: TRawImageLineEnd;
    RedPrec: cardinal;
    RedShift: cardinal;
    GreenPrec: cardinal;
    GreenShift: cardinal;
    BluePrec: cardinal;
    BlueShift: cardinal;
    AlphaPrec: cardinal;
    AlphaShift: cardinal;
    AlphaSeparate: boolean;
    AlphaBitsPerPixel: cardinal;
    AlphaLineEnd: TRawImageLineEnd;

The goal of TLazIntfImage/fpImage is not only to handle interface images, but to work with them. If an application needs information about the image format of a DC, why should it create a bitmap? So, I think, GetDescriptionFromDevice is a useful function.

If the win32 intf needs to create a bitmap to get the needed information, it can create a small bitmap 1x1 and release it instantly.

About CreateBitmapCompatibleToDevice:
I think, you are right. It does not make much sense to create a RawImage from incompatible data. The conversion process should be done by TLazIntfImage and not by the interface. So, I think, I will change TLazIntfmage to store a DC and to use CreateBitmapCompatibleToDevice instead of CreateBitmapFromRawImage. But then we also need a function CreateBitmapCompatibleToBitmap.

Mattias

+ From: Micha Nelissen
+ Sent: donderdag 13 november 2003 8:24
+
+ Marc Weustink wrote:
+
+ > At 17:59 8-11-2003, Micha Nelissen wrote:
+ >
+ >> Do you have any tips how to make a transparency mask so I can
+ >> implement the necessary behaviour?
+ >
+ > Look at the implementation of TransparentStretchBlt +
+ Where is this function defined? I have searched all over the place, but
+ I can't find it. Only reference is in htmllite/litegif2.pas or
+ something alike. But no definition.

It is part of the delphi source, defined in the graphics unit.

Marc