Bug 17664

Summary: wrong handling of infinite coordinates
Product: Mesa Reporter: Stefan Huber <shuber>
Component: Drivers/DRI/i965Assignee: haihao <haihao.xiang>
Status: RESOLVED NOTABUG QA Contact:
Severity: normal    
Priority: medium    
Version: 7.0.3   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: g++ test.cpp -lglut -lGLU -lGL -lSM -lICE -lX11 -lXext -lXmu -lXt -lXi && ./a.out

Description Stefan Huber 2008-09-19 09:15:42 UTC 
Created attachment 19016 [details]
g++ test.cpp -lglut -lGLU -lGL  -lSM -lICE  -lX11 -lXext -lXmu -lXt -lXi && ./a.out

The code below is handled wrong. The quad is stretched, there is a color-gradient, there is alpha...

  glBegin( GL_QUADS );
    glVertex2f( -INFINITY, 0.5 );
    glVertex2f( 0.5, 0.5 );
    glVertex2f( 0.5, 0.2 );
    glVertex2f( -INFINITY, 0.2 );
  glEnd();

I guess, that the problem is not limited to quads. What I expect from the code above is an infinite strip to the left with an vertical width of 0.3. Btw, the code demonstrate also the disappearance of horizontal and vertical lines when enabling smoothing for lines (see bug #9951).

Unfortunately, the code does also not work, if one replaces INFINITE with a big number, like 1e8 or 1e39. This leads to different effects, as test.cpp demonstrates.
Comment 1 Eric Anholt 2009-05-20 18:55:15 UTC 
OpenGL 2.1 spec section 2.1.1:

Any representable floating-point value is legal as input to a GL command that
requires floating-point data. The result of providing a value that is not a floating-point number to such a command is unspecified, but must not lead to GL interrup-tion or termination. In IEEE arithmetic, for example, providing a negative zero or a denormalized number to a GL command yields predictable results, while providing a NaN or an infinity yields unspecified results.

Further, from that section:
We require simply that numbers’ floating-point parts contain enough bits and that their exponent fields are large enough so that individual results of floating-point operations are accurate to about 1 part in 10^5.

You're going to need to specify your vertices in such a way that there's hope that floating point math will get you results you want.
Comment 2 Stefan Huber 2009-05-21 01:30:38 UTC 
Since, from a formal point of view, this is not a bug, can we interpret this bug report as a feature request?

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.