Marc Weustink wrote:
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)
OK
My idea is to let the higher levels (TBitmap/LazIntfImage) decides if
will use Alpha or not:
[..]
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.
[..]
- 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.
It will be two smaller functions with a more specific design dealing
with fewer variables. Currently StretchMaskBlt handles Mask presence,
Alpha presence, Stretch need giving 8 possiblites.
Bugs can be fixed independently. Today fixing a bug in mask support can
break alpha support and vice versa.
It will increase granularity of the api keeping it really low level:
Think of a developer that wants to work with bitmaps in low level using
32bit format but don't want/need to setup the alpha channel. If he calls
StretchMaskBlt, currently, the alpha channel (with garbage data) will be
always used leading to wrong display. There's no way to overcome this.
With the two functions design he can chooses the appropriate functions.
In the end if a "handle all" function is desired in winapi level (i
still think should be in higher levels and is not necessary in low
level) create a function of type "if haschannel do call channel function
else call non channel function"
Luiz
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
