What do you think?
Yes, this looks like the right thing to do.
Cheers, - Andreas
Juan Vuletich wrote:
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@8 depth: 32. f1 fillColor: (Color r: 1.0 g: 1.0 b: 0.7 alpha: 0.6). f2 := Form extent: 8@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@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