[Mesa-dev] [PATCH 2/2] meta: Handle bitmaps with alpha test enabled.
currojerez at riseup.net
Wed Nov 3 13:59:37 PDT 2010
Brian Paul <brianp at vmware.com> writes:
> On 11/03/2010 09:12 AM, Francisco Jerez wrote:
>> Brian Paul<brianp at vmware.com> writes:
>>> On 11/02/2010 12:25 PM, Francisco Jerez wrote:
>>>> We have several options.
>>>> - Fall back to swrast in the floating point renderbuffer case. In other
>>>> cases the conversion to fixed point guarantees that EQUAL will behave
>>>> as expected. Simple and good enough ATM because all the users of
>>>> _mesa_meta_Bitmap don't support floating point color buffers (no-one
>>>> does). Some of them might at some point though.
>>>> - Choose a background alpha value different to the current raster color
>>>> that is known to be represented exactly all the way down the pipeline
>>>> (e.g. 0.0/1.0), then use NOTEQUAL to cull them out.
>>>> - Stick to GREATER/LESS for maximum robustness/paranoia.
>>>> I'm fine with any of them. What do you suggest?
>>> Either of the later two. Thanks.
>> OK, the following patch implements the second one.
> Looks good. Thanks.
> Reviewed-by: Brian Paul <brianp at vmware.com>
> Another thing: it looks like we don't really need to specify vertex
> colors when drawing the bitmap quad. Want to remove/fix that?
I don't expect immediate mode color specification to be much faster than
the current solution, there'd be yet another layer in between and the
constant color would still be copied multiple times on its way down.
We could fix up the color array struct by hand and make it point
directly to the current raster color (kind of a layering violation), or
use flat-shaded quads (more state we'd have to track), but, AFAICT, this
isn't so relevant performance-wise, right now the bottleneck is in the
repeated texture re-uploads and DrawArrays calls.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 229 bytes
Desc: not available
More information about the mesa-dev