On 30.03.2009, at 14:31, Juan Vuletich wrote:

> Bert Freudenberg wrote:
>> On 30.03.2009, at 00:44, Juan Vuletich wrote:
>>
>>> It is a BitBlt bug. Evaluate and print this:
>>>
>>> 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 display.
>>> (f1 colorAt: 2 at 2) alpha
>>>
>>> Rule 28 is rgbMin. The resulting color should be (Color r: 0.5 g:  
>>> 1.0 b: 0.7 alpha: 0.6). But alpha is set to zero. This is a bug,  
>>> and it is what causes wrong alpha values in Display in Cuis.
>>
>> Not a bug per se, it's called rgbMin and not rgbaMin, right?  
>> Besides, even it would take the min of the alpha, then the alpha in  
>> the frame buffer would still not be 1 to indicate opaqueness.
>>
> I believe it is a bug. Reasonable answers would be alpha = 1 (always  
> generate opaque colors), 0.6 (previous destination alpha), 0.7 (max  
> alpha between source and destination) or 0.65 (mean alpha between  
> source and destination). Any of these results would be consistent  
> with the result for other bit depths. Setting alpha to zero means  
> that if the destination depth is 32, rule 28 will always fill  
> destination with transparent, ignoring everything else. I think this  
> can never be the desired result.
>
> BTW, the same problem happens with the following rules:
>   20    rgbAdd: sourceWord with: destinationWord.  Sum of color  
> components
>   21    rgbSub: sourceWord with: destinationWord.  Difference of  
> color components
>   27    rgbMax: sourceWord with: destinationWord.  Max of each color  
> component.
>   28    rgbMin: sourceWord with: destinationWord.  Min of each color  
> component.
>   29    rgbMin: sourceWord bitInvert32 with: destinationWord.  Min  
> with (max-source)
>   37    rgbMul:with:
>
> All these rules are currently useless if destination is 32 bit deep.
>
>> I can't remember what the rgbMin rule is used for. Changing it  
>> might break something, or it might now. Does anyone know?
>>
> It should break nothing. Nobody can be actually using that  
> transparent in a meaningful way.


Not for display purposes. But BitBlt has been used for numeric stuff,  
too, where it would make a difference.

OTOH I agree that making the results in 32 bits match the ones in  
lower bit depths is sensible. Care to send a changeset to vm-dev?

- Bert -