Marc Weustink wrote:
Luiz Americo Pereira Camara wrote:
Luiz Americo Pereira Camara wrote:
The problem is that StretchMaskBlt is calling AlphaBlend and somehow
this is not working.
It seems that TBitmap will have alpha channel by default (or at least
LCL recognizes as having) when running in a display with 32bit color
under win32.
Looking at StretchMaskBlt (the function used by TBitmap to draw) when
a bitmap has alpha (checks if has 32bit depth), each time is draw an
extra bitmap is created and also some other extra calls.
I don't think we need alpha channel by default when using TBitmap to
e.g temporarily draw before sending to the canvas. Maybe a property
could be added to enable alpha support at TBitmap level (when reading
a file or when the user requires it). Another option is to split
StretchMaskBlt
This will be fixed. By default a bitmap should be 24bpp when 32bpp is
available. There was a fix, but at the wrong place. So I removed
removed it when fixing 9501
This solution would bring another performance penalty, when using 32bit
color display, since each time a BitBlt/StretchBlt is called a color
conversion (three times when using mask) will be done.
It also breaks the PixelFormat = pfDevice (the default) idea of having
the most suitable/faster pixel format depending of the display/device.
My idea is to let the higher levels (TBitmap/LazIntfImage) decides if
will use Alpha or not:
- Create a "StrechAlphaBlt" function to use the alpha channel. Let
StretchMaskBlt to handle masked and not transparent bitmaps.
- If an image with alpha channel is loaded or if the user explicitly
requires, an "UseAlpha" flag is set
- When a draw is done if "UseAlpha" is set, use "StretchAlphaBlt"
otherwise StretchMaskBlt
This has some advantages:
- The higher levels (TBitmap/LazIntfImage) will be flexible/able to
handle any format
- TBitmap will use by default the faster pixel format in 32bit color display
- The lower levels functions will be optimized. This would reduce the
size/complexity of StretchMaskBlt helping in the maintainability/code
quality since it will not be a handle all function
What the core developers think?
BTW, a TBitmap has already such property. No need to add another one :)
Half of the way ;-)
Luiz
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
