BitBlt rgbMin bug? (was Re: [squeak-dev] [Ann] Cuis: A new Squeak
distribution)
Juan Vuletich
juan at jvuletich.org
Mon Mar 30 12:31:09 UTC 2009
Bert Freudenberg wrote:
> Folks, it would be really helpful if you adapt the subject when the
> discussion strays from the original topic of a thread. Thanks.
>
Indeed. Apologies.
> Comments below.
>
> 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.
> OTOH, isn't using min for text rendering a hack at best, which only
> works for black text?
>
Yes. A hack at its best! See BitBlt >>
#installStrikeFont:foregroundColor:backgroundColor: (in Cuis). It is the
best I could do without requiring rule 41, that is not always available.
For other colors (not black) I turn off subpixel rendering, and use some
other rule (if possible, 34, alpha blend). See that I chose the rule and
color map carefully for different text color and destination depth.
> - Bert -
>
Cheers,
Juan Vuletich
More information about the Squeak-dev
mailing list
|