22

I'm just learning about them, and find it discouraging that they have been deprecated. Should I keep investing into learning them? Would I learn something useful for the current model?

andandandand
  • 21,946
  • 60
  • 170
  • 271
  • There's a difference between "deprecated" and "removed". FYI. Deprecated stuff isn't usually removed right away. – cHao Nov 06 '10 at 17:18
  • @cHao They only removed from the core, but available in compatibility mode. So they are not completely removed. – Calmarius Dec 03 '13 at 12:43
  • 2
    @Calmarius That's exactly what *deprecated* means in GL. – 3Dave Nov 11 '16 at 01:23

5 Answers5

26

I think, though I may be wrong, that since most high-performance graphics apps (mostly games) pretty much only used vertex buffers and the like (in order to squeeze every drop of performance out of the card), that there was pressure to stop worrying about "frivolous" items such as display lists (and even good-old glVertex calls). IMHO, this provides a huge barrier to people learning to write OpenGL code, and (for my own purposes) is a big impediment to whipping up some quick, legible, and reasonably well performing code.

Note that these features were deprecated in 3.0, and actually removed in 3.1 (but still provided compatibility via an ARB extension). In OpenGL 3.2, they moved these features into a 'compatibility' profile that is optional for driver writers to implement.

So what does this mean? NVidia, at least, has vowed to continue support for the old-school compatibility mode for the forseeable future - there is a large wealth of legacy code out there that they need to support. You can find the discussion of their support in a slideshow at:

http://www.slideshare.net/Mark_Kilgard/opengl-32-and-more

starting at about slide #32. I don't know ATI/AMD's stance on this, but I would assume that it would be similar.

So, while display lists are technically removed from the required portion of the OpenGL 3.2 standard, I think that you are safe using them for quite a while. Eventually, you may wish to learn the buffer/shader-centric interface to OpenGL, especially if your end-goal is envelope-pushing game writing, but it really is a lot less intuitive (no glRotate, even!), so I would recommend starting with good old OpenGL 2.x.

-matt

Gretchen
  • 2,274
  • 17
  • 16
  • 5
    Found the following on the AMD GL3 white paper (http://developer.amd.com/gpu_assets/GL3_WhitePaper.pdf): "AMD currently has no plans to remove any of these deprecated and removed items from non-forward compatible OpenGL contexts. AMD plans to support the features and interfaces currently in widespread use among many code-bases." – Gretchen Nov 06 '10 at 21:35
  • 6
    *"this provides a huge barrier to people learning to write OpenGL code, and (for my own purposes) is a big impediment to whipping up some quick, legible, and reasonably well performing code"* - OpenGL should be considered a low-level graphics API, hence talking in terms of "memory buffer objects" and "attribute pointers" is appropriate. For whipping up quick code, a graphics engine like Irrlicht or Ogre or Horde3D or perhaps Cinder may be more appropriate. – Kos Jan 08 '13 at 17:10
  • 8
    That said, whipping up quick code in core OpenGL 3 or 4 isn't *that* hard. Adding vertices to a `std::vector` isn't more complicated than `glVertex` commands, and shaders are a lot simpler than `glLight` and `glTextureEnv`. There's indeed some boilerplate code to handle, but most of it is linear algebra that's best settled with a library like GLM. I say: Forget display lists, go with core OpenGL. – Kos Jan 08 '13 at 17:14
  • @Kos don't forget the overhead of reading and compiling your shaders and checking info logs... – user253751 Apr 13 '22 at 17:36
  • and learning c++? – m4r35n357 Jan 18 '23 at 16:34
6

Display lists were removed, because with opengl 3+ all vertex, texture and lighting data are stored on the graphics card, in what is called retained mode rendering (the data is retained, allowing you to send a single command to the card to draw a mesh, rather than sending vertex data to the card every frame). A major bottleneck in computer graphics is data bandwidth between RAM and gpuRAM. by generating meshes once, and retaining that data, we can transform it using homogeneous transform matrices, and draw it easily. This effectively reduces the bottleneck, with the drawback of longer loading times. Immediate mode, however (pre 3.0) uses massive amounts of graphics bandwidth to send vertex data every frame, pre-transformed, with recalculated normals etc. The problems with this approach are twofold: 1) excessive bandwidth use, and too much gpu idle time. 2) Excessive use of cpu time for calculations that could be done in parallel on 100+ cores, on the gpu

The simple solution to this, is retained mode.

With retained mode, display lists are no longer necessary. Hence their removal from the core profile.

Immediate mode is still very good for learning the theory of computer graphics. (and it's loads of fun, to boot) It just suffers in terms of maximum possible performance.

VBOs & VAOs may be, at first, less intuitive, but in terms of speed, it is far superior.

There are several easy to understand opengl 3.0 tutorials on the internet. Once you have openGL 2.0 down, you should consider moving on to 3.0+, as it allows you to build very fast 3d graphics applications.

Ian Young
  • 1,712
  • 1
  • 16
  • 33
2

While Matthew Hall has a good answer and covers most things, there are a few things I'll add.

If you look at what's been deprecated, you'll see it's a lot of client side and fixed functionality. So it's obvious that they're trying to move people away from client side centered code and have people do everything possible server side on the GPU instead.

When it comes to which context to use, well, that's up to you. Though if performance is a major concerned then 3.x is probably the way to go. I personally definitely want to learn opengl 3.x, but I doubt I'll be giving up 1.x/2.x. It's just so much easier to put together a quick app with what's available in a 1.x or 2.x context.

If you want a list of what's been deprecated, download the 3.0 specification and look under "The Deprecation Model"

jay.lee
  • 19,388
  • 8
  • 39
  • 38
2

A note from the future: latest Direct-X, Metal, and Vulkan apis have command buffers and command queues, which allow to record commands in the CPU, then sent them to the GPU to execute them there. Thus, perhaps, display lists was not a so old-fashioned idea. In fact, compiling display list is something orthogonal to the use of shaders and VBOs, and display lists can improve performance further....I wonder if a Vulkan or Metal to OpenGL translator could use display lists for command buffers....

user5122888
  • 309
  • 3
  • 5
  • fully agree with you here, in fact i would think a display list which starts with `glPushAttrib` and ends with `glPopAttrib` would be able to be optimized very well by a modern driver, since it would essentially encapsulate the entire render state in a single object, exactly like a command buffer from the more modern graphics APIs. (especially if `glPushAttrib` were followed by some imaginary command which resets all server attributes to their default values, like `glLoadIdentity` but for all attributes) – DaPorkchop_ Jun 21 '23 at 10:26
1

Because VBOs (vertex buffer objects) are much more efficient and can do everything display lists can do. They're not really any more complex, either, just a little different. Unless you're already more familiar with the old style glBegin/glEnd stuff, you're probably best off learning about buffers from the get go.

Chris Dodd
  • 119,907
  • 13
  • 134
  • 226
  • 4
    no, VBO can't do everything display lists can. e.g. nvidia's professional driver store state changes in optimized form and potentially execute them on a secondary thread. – Bahbar Nov 07 '10 at 13:22
  • OpenGL Wiki FAQ says "If and only if there is a requirement to maintain existing legacy code and there is no way to rewrite the rendering system, using display lists can be quite advantageous in comparison to vertex arrays for static data. If dynamic updates are required, there is no way arround vertex arrays." – legends2k Apr 15 '13 at 08:04
  • @Bahbar: That's besides the point. Perhaps VAO can do it almost close and perhaps looses in a small number when compared piece-meal wise but looking at the bigger picture there's a big win (in both perf. and flexibility) in moving to the modern shader-based pipeline. – legends2k Apr 15 '13 at 08:07
  • 4
    @legends2k: You seem to think display lists can only store vertex data. That's not the case. Display lists can _in theory_ accelerate any part of the API stream, not just vertex data submission. In practice, they're a mess to implement correctly, harder to implement efficiently, hard to layer middleware on top of, and various other reasons. But they're not _redundant_ with VBOs. – Bahbar Apr 15 '13 at 11:18