[lazarus] Bitmap transparency?

[Mattias Gaertner]

On Sun, 09 Nov 2003 18:23:39 +0100
Micha Nelissen <M.Nelissen at student.tue.nl> wrote:

> Mattias Gaertner wrote:
> 
> > On Sun, 09 Nov 2003 15:08:06 +0100
> > Micha Nelissen <M.Nelissen at student.tue.nl> wrote:
> >>
> >>I have been looking, but I can't find it in the archives / code: what 
> >>functions do I need to implement?
> > 
> > 
> > See winapih.inc, search for RawImage.
> > See graphtype.pp for the RawImage format. 
> > intfgraphics.pas contains the TLazIntfImage which uses the 5 functions.
> 
> Is GetDescriptionFromDevice only used to create a device compatible 
> bitmap? 

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.


> 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. 

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. 


> 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.

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