Because it is related to fixed function OpenGL and as such had to be removed to provide a more general framework.
Anyway, migration is not that difficult as it might look at first sight and on the way you’ll see that its mean is to provide even more flexibility and less hard coded functionality.
In this specific case, the code conversion impact isn’t that great (unless you have batch setup calls spread all over your app rather than having a “drawable batch”-type class. Other things like deprecating gl_ModelViewMatrix, gl_ProjectionMatrix, etc. have bigger code impacts.
Why did they kill most gl_* built-ins in GLSL 1.3? Well, back in the GL 3.0 days, the prevailing ARB view was that OpenGL would just obsolete the entire fixed-function pipeline. Didn’t think much about legacy app port cost or newbie startup. The former turned out to be an obstacle. That’s why the compatibility profile is there – all this stuff still exists in it.
It was removed because it is inefficient and it bloats the front end with arbitrary vertex and atribute issue order and density.
Using vertex immediate mode dispatch in a modern app is ridiculous unless it’s some rinky-dink test and/or you’re display listing, and then you want to look at other mechanisms.
The fact is hardware has moved on and and competent programmer should be able to package vertex data into attribute arrays, bind them and issue them with a single call. Further you should be indexing for vertex cache otherwise you’re taking a significant hit. On top of this bad developers used to write war & peace per vertex compounding the problem. This way you have fewer methods to shoot yourself in the foot.
You also have vram memory resident mechanisms to exploit and pulling data onto the call stack is just awful.
Try it, you will get used to it VERY quickly.
Remember that there are no preferred attribute slots and invoking attributes per vertex now. With the clean fully deprecated version of the API you’re sending bound arrays to shader attribute registers. So the question of which attribute is the invoking one need not arise when you simply have an attribute per vertex bound.
So, reasons glVertex() sucks:
Calls per vertex are slow
Sparse vertex attributes and arbitrary issue order convolutes the front end
There is no mechanism to exploit vertex cache
It defeats vram resident attribute mechanisms (VBOs) (display lists would be the old alternative)
There is no need for an invoking attribute using MODERN shaders
Bad/naive developers wrote a lot of crap between glBegin and glEnd
This minor convenience only supplies opportunities to write very slow graphics code, even when used well
He’s not talking about glVertex(), but rather gl_Vertex (GLSL vertex attribute built-in).
Which you can populate using glVertexPointer so which has nothing to do with immediate mode, supporting both client arrays and VBOs.
Of course in “the new world order”, use your own shader vertex attribute name, populate it using glVertexAttribPointer, and link them up using glBindAttribLocation.