Talk:Legacy OpenGL

From OpenGL.org
Jump to: navigation, search

Not happy with page

Personally I'm still far from being happy with this page. Does anyone have a problem with summarizing deprecated features as is done in the 3.0 spec in the corresponding sections? Another thing I really can't understand is why people equate immediate mode to legacy OpenGL. Also, the reasons why one should use modern OpenGL are vague and incomprehensive. We should provide precise and convincing examples and offer a real explanation of the matter. Any content-related objections? thokra (talk) 09:56, 5 September 2012 (PDT)

You can summarize it if you wish, but really, it'd just be a copy-and-paste job from the spec. Also, it would be a very large section, so it would be best if it were moved to the bottom.
As for why "immediate mode" is equated to "legacy OpenGL", that's because it's been removed from core OpenGL 3.1 and above. That's how this page defines "legacy": the stuff that's been removed. As for "precise and convincing examples", it's up to each individual person to decide what is "precise and convincing". Alfonse (talk) 10:06, 5 September 2012 (PDT)
My intention was to provide the reader of the Wiki with a list that would make it unnecessary to look at the spec merely to figure out what's not in the spec anymore. But yes, it's a thoughtless process. My problem with "immediate mode" for "legacy OpenGL" is that legacy doesn't only refer to primitive specification. thokra (talk) 11:03, 5 September 2012 (PDT)

Alfonse, regarding your correction that you need at least two API calls to render something, that is true if you take binding into account - and possibly pointer setup. That's fine with me. However, I thought of the case where everything is already bound and setup sp only a draw called has to be issued. In many of my use cases I manage buffer binding and pointer setup as independently from draw code as possible. Should we add some more clarification on this? thokra (talk) 11:56, 11 September 2012 (PDT)

By that logic, it also only takes 1 API call to render with legacy OpenGL (via client-side vertex arrays). After all, if you're going to ignore the glBindVertexArray call, then you should also ignore the gl*Pointer calls the Legacy GL API would have to make. It's only fair. Alfonse (talk) 14:46, 11 September 2012 (PDT)

I wasn't sure about the shadow mapping stuff. Have the corresponding extensions been adopted into core at some point? Also, I wasn't sure about the right formatting. I started out with a bulleted list but moved to bold headings. Somehow, both versions don't look too amazing. thokra (talk) 13:14, 11 September 2012 (PDT)

Issue of being a specification

I don't understand the frequent claim that OpenGL is not a library, it is a specification. What else could it be? And in what way would that affect a user? To the user, there is no difference if a document is a specification or a description of an implementation. They are equally valid and useful. Possibly, a difference would be that a proper specification never repeats anything. Redundancy should be avoided. Another difference could be that a specification has to be valid for all implementations, but documentation of a specific implementation does not have to be valid for other implementations. But again, that is not a problem with for users at this site, is it? And the comparison with TCP/IP isn't valid? TCP/IP is a specification of a protocol, not the API to use TCP/IP. But OpenGL specifies the API. Kopelrativ (talk) 12:32, 18 October 2012 (PDT)

A library is software - OpenGL isn't software. Period. An implementation isn't entirely valid until it conforms fully to the specification - not the other way around as you suggest. There is no specific implementation, there are implementations which implement the central specification. The comparison with TCP/IP is valid because it specifies a protocol (two protocols actually) and the TCP/IP stacks of implementing operating systems implement it. It's the exact same thing as with OpenGL. thokra (talk) 13:16, 18 October 2012 (PDT)
There is a big difference between a "description of an implementation" and a "specification". In the former, if the use of the implementation does not match with the implementation's behavior, then more likely than not, it is the description that is wrong. However, if an implementation of a specification differs from what the specification says, it is the implementation that is wrong.
To put it another way, think back to the GLide days. If the docs for GLide could say one thing, but since GLide was build on 3Dfx's specific hardware, it's clear that the docs were simply wrong. You coded to what GLide did, not what the docs say GLide does. With OpenGL, you're (theoretically) supposed to code to the specification. This (theoretically) ensures that your code works the same across all OpenGL implementations. And if it doesn't, then it's the implementations fault, not yours or the spec. A proper specification makes it possible to assign blame for a program's failure to work.
As far as library vs. specification, OpenGL isn't a library. A library is a concrete construct, a specific set of compiled object files and/or header files and/or whatever any particular language needs to use it. On Windows, "OpenGL" is provided by a combination of OpenGL32.dll (which is a library), and an installed .dll (which is a different library), as well as the various Windows-specific libraries needed to create and manage a window. So it is wrong to say that OpenGL is a library. You can't point to a single file or distribution and say, "That's OpenGL." Not for a single platform, and certainly not across platforms.
Lastly, while the OpenGL specification does define the API, it does not define the language for that API. It simply says, "there will be a function named this, that takes parameters of 'type' this, and returns values of 'type' this." That's not very different from a communication protocol: input is formatted like this, output is formatted like this, and everyone's happy. Alfonse (talk) 01:47, 19 October 2012 (PDT)