[Vm-dev] [Bug] Bug in BitBlt (rgbMin and other set alpha to 0)
juan at jvuletich.org
Tue Mar 31 17:23:02 UTC 2009
I found a bug in BitBlt. The following rules:
will set alpha = 0 if the destination is 32 bit deep. This means that if
the destination is 32bpp, these rules are useless, as they will ignore
source and destination and always set all the pixels to transparent.
To test, try printing:
f1 := Form extent: 8 at 8 depth: 32.
f1 fillColor: (Color r: 1.0 g: 1.0 b: 0.7 alpha: 0.6).
f2 := Form extent: 8 at 8 depth: 32.
f2 fillColor: (Color r: 0.5 g: 1.0 b: 0.7 alpha: 0.7).
bb :=(BitBlt toForm: f1) sourceForm: f2; combinationRule: 28; copyBits.
(f1 colorAt: 2 at 2) alpha
The fix I propose is in the last line of all those methods, to change
'nBits: 8 nPartitions: 3' to read 'nBits: 8 nPartitions: 4'. This would
make all these operations to treat alpha as they treat red, green and
blue. This could have some performance impact. Reasonable alternatives
includes leaving alpha unchanged, set it to 255 (opaque), or set it to
(source max: destination).
What do you think?
More information about the Vm-dev