Brian Paul <bri...@vmware.com> writes:
> [...]
>>
>> - bitmap8 = (GLubyte *) calloc(1, width * height);
>> + bitmap8 = (GLubyte *) malloc(width * height);
>> if (bitmap8) {
>> + memset(bitmap8, ~alpha, width * height);
>> _mesa_expand_bitmap(width, height, &unpackSave, bitmap1,
>> - bitmap8, width, 0xff);
>> + bitmap8, width, alpha);
>>
>> _mesa_set_enable(ctx, tex->Target, GL_TRUE);
>>
>> _mesa_set_enable(ctx, GL_ALPHA_TEST, GL_TRUE);
>> - _mesa_AlphaFunc(GL_GREATER, 0.0);
>> + _mesa_AlphaFunc(GL_EQUAL, ctx->Current.RasterColor[ACOMP]);
>
> I think the code in this area should stay as-is. If the ubyte value
> in the texture is converted to float, that might produce a value
> that's different from the alpha you're specifying to
> _mesa_AlphaFunc(). The test for equality could fail unexpectedly.
>
> The original code is more robust in that regard.What if the current raster alpha value is non-0xff? I changed the original code because that case was misrendered. I understand your concern though. According to the spec both reference and fragment alpha values are converted to the nearest fixed-point value (of unspecified but same precision) before comparison, so AFAICT this change should cause no problems as long as we observe the same rules in the raster color to texture value conversion. I'll reply to myself with a split version of this patch so that we can discuss both changes separately. I've made it use CLAMPED_FLOAT_TO_UBYTE as additional paranoia to avoid rounding errors in the alpha conversion. > > >> setup_drawpix_texture(ctx, tex, newTex, texIntFormat, width, height, >> GL_ALPHA, GL_UNSIGNED_BYTE, bitmap8); >> -- 1.6.4.4 > > -Brian
pgpTyAgzevFAp.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
