This introduces a new CMake option - WITH_LEGACY_OPENGL. Without this option
things may not draw perfectly, however, we should soon be able to build with
OpenGL core profile.
The matrix-related api calls are (still) not handled here (glTranslate, ...).
There seems to be no consensus on whether to make this build option the
default. We can talk about this later. For now two things are the
priority:
(1) To get rid of deprecated calls when WITH_LEGACY_OPENGL is ON
(2) To make core profile work for Mesa/Mac when WITH_LEGACY_OPENGL is OFF
Reviewers: merwin, sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2603
Many thanks for Sergey Sharybin for the help.
See intern/gawain for the API change. Other files are updated to use the new name. Also updated every call site to the recommended style:
unsigned int foo = VertexFormat_add_attrib(format, "foo", COMP_ ... )
Reference document: http://docs.gl/gl3/glPushAttrib
This patch only tackles the bits that are set by Blender with the
following exceptions:
1) Deprecated states (e.g., GL_STIPPLE) are not saved/restored
2) The exception being GL_ALPHA_TEST, which will be removed, but it may
affect drawing too much now. To be removed once we no longer set GL_ALPHA_TEST
elsewhere.
3) paint_cursor will be tackled separated, since it was abusing
glPush/PopAttrib in the first place.
4) Despite what the glPushAttrib page above may suggest, GL_DEPTH_WRITEMASK needs glGet, not glIsEnabled
5) BGE is still a problem since it relies on GL_ALL_ATTRIB_BITS which
would lead to a way more complete/lenghty solution. Since the BGE has
other (OpenGL deprecated) problems anyways, it can be handled on its own
time.
Finally, the original design for 2.8 was to implement a proper stack
system. However we need to move to core profile sooner than later. So
this is a pragmatic temporary (that may be permanent) solution.
Reviewers: merwin, campbellbarton
Differential Revision: https://developer.blender.org/D2600
These bits became obsolete with the new layer system, so we can
simplify some code around them or avoid existing workarounds which
were trying to keep things working for them.
There are still work needed to be done for on_visible_change to
avoid unnecessary updates, but that can also happen later.
Core of the issue was that some of our Theme colors are RGB-only, but
were loaded as RGBA.
Note that tracking all possible cases is pretty impossible, so we'll
have to tackle those as they get reported am afraid.
