Option to drop all legacy OpenGL
Posted Tuesday, 4 May, 2010 - 12:12 by tksuoran| Project: | The Open Toolkit library |
| Version: | 1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | confirmed |
Jump to:
Description
I would very much like to have option to drop everything legacy, deprecated and removed stuff in OpenGL 3.3/4.0.
Having this in mind, names like 'BeginMode' seem a bit funny if/when Begin and End is removed.
Comments
#1
I see it as a subtask of a general problem:
restrict function/enums usage based on their GL version
This can be used for cutting of deprecated features and preventing usage of others whose requirements are not met (e.g. TransformFeedback core requires GL-3.1).
I have no idea how this can be implemented ATM.
#2
Marking and removing deprecated functions is on my todo list for 1.1. It is a relatively simple modification to the binding generator (simply check for the "deprecated" symbol in gl.spec and glext.spec and mark or omit those functions) that unfortunately has some not-so-simple implications (how do we handle binary compatibility, should we also search for and remove enums that are only used by deprecated methods)?
Kvark's suggestion is a slightly different topic. I don't know how feasible this is: since we don't know if a specific feature is available until runtime, we cannot prevent its usage at compile time. However, what we can do is mark which functions require which OpenGL version (this information is available in the specs) and/or try to mark which enums require which OpenGL version (this information is not available in all cases but might be possible to infer indirectly, i.e. enum Foo is used by methods X/Y/Z, so it requires min-version-of(X, Y, Z)).
Still, this discussion probably belongs to a different issue.
#3
(Discussion moved here: http://www.opentk.com/node/1755)
#4
Functions are now documentated with a required version and/or extension. The generator has an option to add deprecation warnings and it should now be trivial to add a [Conditional("DEPRECATED")] attribute to all deprecated methods. With that, creating a "forward-compatible" dll will be just a matter of #defining DEPRECATED in the project options.
Any takers?