[Vm-dev] [Bug] Bug in BitBlt (rgbMin and other set alpha to 0)

Juan Vuletich juan at jvuletich.org
Tue Mar 31 17:23:02 UTC 2009


Hi Folks,

I found a bug in BitBlt. The following rules:
  20    rgbAdd:with:
  21    rgbSub:with:
  27    rgbMax:with
  28    rgbMin:with:
  29    rgbMinInvert:with:
  37    rgbMul:with:
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?

Thanks,
Juan Vuletich


More information about the Vm-dev mailing list