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

[Andreas Raab]

 > 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 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
>