[Mesa-dev] [PATCH 2/2] meta: Handle bitmaps with alpha test enabled.
Francisco Jerez
currojerez at riseup.net
Mon Nov 1 19:02:00 PDT 2010
Brian Paul <brianp at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 229 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20101102/d9d01a55/attachment.pgp>
More information about the mesa-dev
mailing list