Bug 4992 - glClear vs rendering with 16 bits per channel
Summary: glClear vs rendering with 16 bits per channel
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: git
Hardware: x86 (IA32) Windows (All)
: low minor
Assignee: mesa-dev
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-11-08 08:54 UTC by Roy Walmsley
Modified: 2009-08-24 12:23 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Roy Walmsley 2005-11-08 08:54:26 UTC
When comparing the pixel colours from glClear and normal rendering it was found 
that the same colour differed by one pixel value. This was found to be caused 
by glClear (in s_buffers.c, function clear_rgba_buffer) using the macro 
FLOAT_TO_USHORT which truncates while the normal rendering pipeline (in 
t_vertex_generic.c) uses the macro UNCLAMPED_FLOAT_TO_USHORT which rounds. So 
for a pixel value expected to be 2.52 the glClear calculated 2 and the 
rendering pipeline calculated 3.

This was resolved simply resolved by substituting the latted macro in the 
glClear case. Therefore the lines 135 to 138 were changed to 

         UNCLAMPED_FLOAT_TO_USHORT(clear16[0], ctx->Color.ClearColor[0]);
         UNCLAMPED_FLOAT_TO_USHORT(clear16[1], ctx->Color.ClearColor[1]);
         UNCLAMPED_FLOAT_TO_USHORT(clear16[2], ctx->Color.ClearColor[2]);
         UNCLAMPED_FLOAT_TO_USHORT(clear16[3], ctx->Color.ClearColor[3]);

This resolved the problem for this specific instance.
Comment 1 Brian Paul 2005-11-08 17:17:59 UTC
Fixed in CVS.  Thanks.
Comment 2 Adam Jackson 2009-08-24 12:23:34 UTC
Mass version move, cvs -> git


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.