These were both super-useful features for writing 3D editing software, and my program is worse in OpenGL 4 for their loss. It would be extremely difficult to reproduce the stipple appearance in a shader, and thick lines are better for more highly visible editor guides.
Could you do a little research or at least ask a question on another section of the forum before deciding to post a suggestion?
glLineWidth other than 1.0 is deprecated, but you can use it in compatibility profile. If you want to use core profile, then you shouldn’t complain about deprecation of exotic functionality that doesn’t map to hardware. Same goes for line\polygon stipple.
Line width other than 1.0 is not guaranteed to be supported by hardware. You can draw lines of any width with polygons (extra nice using geometry shader) without relying onto some “magic”(there’s not much information on how it is implemented) line drawing functionality. I doubt that modern hardware has any dedicated functionality for that.
And same with line\polygon stipple, only it is 99% positive, that it is not supported by hardware, it’s just emulated with texturing\internal shader. And you can do it as well, you can also use GS.
So your suggestion is to “un-deprecate” those? Because “These were both super-useful features for writing 3D editing software, and my program is worse in OpenGL 4 for their loss”? OpenGL is not a graphics library to provide you with bells and whistles. It is an API, that maps to hardware functionality. All those extra features you should implement yourself with provided rendering and computation functionality or, alternatively, use 3rd-party libraries which do it already . That’s how modern graphics API’s(not only OpenGL) work.
The ARB didn’t remove Line Width back in GL 3.1 as they did with all the other GL3.0 deprecated features. I’m guessing this is because you can query the line with range and granularity from the driver, so individual implementations may decide how they want to support it. (Nvidia 670, 0.5 to 10 in 0.125 steps; AMD 6950, 1.0 to 63.0 in 0.125 steps). As long as you stay within the line width range of the driver, you can use wide lines.
The implementation may still emulate wide lines and report back capabilities based on the emulation, and this would be prefectly legal so long as it remained conformant (e.g I could imagine a non-conformant implementation exploding if you tried to use wide lines in conjunction with a GS which I guess is possibly a combination that’s rarely, if ever, used).
The days of OpenGL specifying idealized functionality which hardware must then emulate in software are over, thankfully. It’s better to have predictable and robust behaviour that doesn’t suddenly and unexpectedly throw you off the fast path (or drop you back to full software emulation of the entire pipeline on a significant percentage of your target hardware), even if it’s at the expense of reduced functionality or having to code up something extra yourself.
The specified min/max of the aliased and smooth line width range is 1,1. So it’s perfectly valid for an implementation to not support wide or thin lines at all, which is why you need to check the range via glGetFloatv(GL_ALISED_LINE_WIDTH_RANGE, [vec2]) or glGetFloatv(GL_SMOOTH_LINE_WIDTH_RANGE, [vec2]).