Luiz Americo Pereira Camara wrote:
- 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.
I forgot to say that it will not be necessary to add code to convert
from 32bit -> 24bit and not necessary to rework the
CreateCompatibleBitmap and CreateDIBSection functions (with
unpredictable consequences/bugs). And maybe other changes should be
necessary.
In the end, the "one function handles all" approach will need much more
code to debug/maintain.
Also the old StretchMaskBlt function has already been tested widely,
being necessary to debug mostly the alpha enabled function
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
