-
Notifications
You must be signed in to change notification settings - Fork 5
OpenGL::Modern Development
This page is a list of plans for development of OpenGL::Modern including the changes needed in the existing OpenGL modules to support the transition to modern OpenGL APIs and yet maintain the degree of back compatibility with the legacy implementation and to provide developers a reasonable upgrade path.
The current Perl OpenGL module implements bindings to the original OpenGL fixed-function rendering model. It includes support for modern API features such as buffers and shaders by the OpenGL extension mechanism. However, since OpenGL 3.1 the original OpenGL 1.x and 2.x functions have been deprecated and are only available in a compatibility mode which is unsupported and unsupportable for many new graphics devices such as cell phones and tablets. In addition, the OpenGL module includes a number of sub-modules that seemed necessary at the time. Now, it is clear that an implementation where these implicit dependencies become actual perl modules of their own will allow a cleaner implementation and allow legacy Perl OpenGL users to make use of OpenGL::Modern API features while keeping such implicit module functions available for use---at least until better options are implemented. Here is a list of issues by module.
This provides XS bindings to the constants from OpenGL, GLU, and [Free]GLUT. The bindings for OpenGL constants can be replaced by the corresponding implementation from OpenGL::Modern which supports OpenGL APIs from 1.x through 4.x via its use of the GLEW library to generate the bindings code.
We need to split out the GLU and GLUT constants into OpenGL::GLU and OpenGL::GLUT (or OpenGL::GLU::Const and OpenGL::GLUT::Const) respectively. Another idea was to use the perl constant pragma which should allow the perl interpreter to optimize the constants away. I'm not sure this is reasonable since I don't know what happens to the unused constant values on compile...do they stay around leading larger executables or is the memory returned to the system keeping the perl runtime size small and lean?
The GLU library bindings need to be split into their own module. They should have been a separate package all along. Now that the tessellation support is in the core via tessellation shaders, it is clear that it is a separate functionality and deserves a package of its own.