Luiz Americo Pereira Camara wrote:
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.
yes there will be some differences. there is no penalty between 24 or 32
bpp. (except what we introduce)
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
I don't want to use different functions between alpha and non alpha.
IMO, the current vcl/windows implementation is completely alpha unaware.
I want to avoid that.
So blitting an alpha image will use alpha, blitting a non alpha image no
alpha. The Usealpha flag is implicit. It has no meaning for nonalpha images.
This has some advantages:
- The higher levels (TBitmap/LazIntfImage) will be flexible/able to
handle any format
they still can.
- TBitmap will use by default the faster pixel format in 32bit color
display
again, using 24bpp on 32bpp has no speed penalty (given that a pixel
still occupies 4 bytes)
- 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
Now there is one function, otherwise you have to maintain 2.
Marc
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
