PDA

View Full Version : A taxonomical question about glClear



digital_photon
05-12-2011, 07:40 AM
Since glClear is responsible for clearing the window, why is it part of the openGL library? I thought openGL didn't have any windowing-specific code.

BionicBytes
05-12-2011, 08:14 AM
glClear clears the buffer(s) associated to the 'window', of which there are potentially several. The 'window' to which you are refering is provided by the glue mechanisum which Windows OS, MAC OS, Linux, etc use to associate the various buffers to the rendering context.

So OpenGL itself does not have any window manipulation functions, but it does not mean that OpenGL can't manipulate the memory buffers behind the scene.

digital_photon
05-12-2011, 09:29 AM
I see.

But it seems that on windows you need to include "windows.h" before either "glu.h" or "gl.h". Doesn't this imply some amount of dependance on the underlying windowing system?

I would have thought that in an ideal hardware-independant library the header file (which only defines the functions) should have been the same for all implementations. Correct me if I'm wrong.

Alfonse Reinheart
05-12-2011, 02:04 PM
But it seems that on windows you need to include "windows.h" before either "glu.h" or "gl.h". Doesn't this imply some amount of dependance on the underlying windowing system?

Since when did "gl.h" require including "windows.h" before it? The windows version of "gl.h" includes "windows.h" inside itself.


I would have thought that in an ideal hardware-independant library the header file (which only defines the functions) should have been the same for all implementations.

Um, why? Different compilers use different sizes for various data types. But OpenGL defines specific types that have a particular size. GLint must be 32-bits on all machines. Therefore, every environment must define GLint to be a type 32-bits in size. It doesn't matter if one platform defines it as in "int" while another uses a compiler-specific type or something else. What matters is that GLint will have the size that the OpenGL spec says it does.

Dan Bartlett
05-12-2011, 04:29 PM
OpenGL is just a specification, it is up to the (usually GPU hardware) companies who license OpenGL how they implement it.

Implementations don't need to define GLint as 32-bit according to the spec, it just needs to be a "signed twos complement binary integer" of at least 32 bits.

I doubt there are any OpenGL implementations that use anything other than 32bit for GLint though, but this is just a convenience thing agreed by the different implementors, to make things consistent for application developers.

When OpenCL was first being released, on Win32 you had AMD and NVidia releasing implementations with different calling conventions + one had mangled function names, but the other didn't, and it was a pain to use both. Because they both now use undecorated stdcall functions + callbacks, it is now easier to write applications that can use both.

The only things that typically vary between different OpenGL implementations are things that vary between platform, and are usually the same across all implementations on that platform, such as GLintptr being the same size as a pointer (spec only says it needs to be at least large enough to store a pointer), and the calling convention used. You should use the OpenGL types rather than programming language defined types eg. GLint rather than int when dealing with OpenGL though, because even though they may be the same size on your current platform, they might not be on other platforms/implementations.

As for glClear, if you bind a framebuffer object, you will clear that instead of any window system provided framebuffer, and glClear is also affect by certain other pieces of OpenGL state:


When Clear is called, the only per-fragment operations that are applied (if enabled) are the pixel ownership test, the scissor test, and dithering. The masking operations described in section 4.2.2 are also applied. If a buffer is not present, then a Clear directed at that buffer has no effect.

Calling glClear once per frame to clear the depth buffer can help implementations perform a few extra optimizations (not sure if partially clearing a buffer with scissor test enabled allows these optimizations to occur or not), but clearing the color buffer isn't really necessary if you are going to be drawing an opaque object to every pixel anyway.

digital_photon
05-12-2011, 08:39 PM
Since when did "gl.h" require including "windows.h" before it? The windows version of "gl.h" includes "windows.h" inside itself

Microsoft Windows requires that windows.h be included before either gl.h or glu.h, because some macros used internally in the Microsoft Windows version of gl.h and glu.h are defined in windows.h - OpenGL Programming Guide, 7th Edition.

Anyway, I guess Dan's explanation cleared it all up: OpenGL is just a specification, the implementations are upto the individual companies.

Thanks everyone.