[lazarus] Bitmap transparency?

[Mattias Gaertner]

On Sat, 08 Nov 2003 18:15:13 +0100
Marc Weustink <marc at dommelstein.net> wrote:

> At 17:59 8-11-2003, Micha Nelissen wrote:
> >Andrew Johnson wrote:
> >
> >>On Sat, 2003-11-08 at 10:56, 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. :)
> >
> >Yes, but the LCL depends on this 'native' pixmap support for
> >transparency.

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

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



Mattias