Folks, it would be really helpful if you adapt the subject when the  
discussion strays from the original topic of a thread. Thanks.

Comments below.

On 30.03.2009, at 00:44, Juan Vuletich wrote:

> Bert Freudenberg wrote:
>>
>> On 28.03.2009, at 13:31, Juan Vuletich wrote:
>>
>>> Damien Cassou wrote:
>>>> The content looks very ugly when using a composite window manager  
>>>> (I'm
>>>> on Ubuntu with Compiz). When switching off compiz, things looks ok.
>>>>
>>> If I remeber correctly, these kind of problems also happened with  
>>> other Squeak distributions and was due to a kind of bug in BitBlt,  
>>> right?
>>
>> Not a BitBlt bug, but how BitBlt is used. If all drawing operations  
>> would set the Display's alpha component to 1 then it would be fully  
>> opaque.
>>
> 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 can't remember what the rgbMin rule is used for. Changing it might  
break something, or it might now. Does anyone know?

OTOH, isn't using min for text rendering a hack at best, which only  
works for black text?

- Bert -