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.
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.
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.