kvark's picture

Restrict function/enums usage based on their GL version

(Moved from #1753: Option to drop all legacy OpenGL).

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.

As a possible solution to my request:
Insert an assertion (at the beginning of each function) (only for debug mode) with a version check.
The version required by the function is known at compile time. The version of the context should be known as well as user requests it in the run-time.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture

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)).

OpenTK does throw exceptions for unsupported functions already:

  • NullReferenceException/MethodNotFoundException if you try to use a feature from a GL version newer than the one exposed by the drivers (debug & release versions)
  • OpenGLErrorException if you try to use a deprecated feature in a forward-compatible context (debug version only)

Would the assert cover cases other than those two, above?

kvark's picture

No, I guess, what you have is pretty enough.

Aside from this, it would be nice to have a separate GL3 namespace.

nythrix's picture

This thread reminds me of an old discussion. Nowadays the situation is a bit more complicated but some points in there still hold.

tksuoran's picture

Bump.. What is the status of 1.1 and will there be core assembly without removed stuff?

I would also like to put each API into separate assembly, since I want to reduce the size of the dll's needed. OpenTK is currently 10x size of other stuff and I know it carries mostly stuff I don't use :-|

the Fiddler's picture

Separate assemblies are planned for OpenTK 2.0. I am testing a few other ideas to reduce the dll size before that - results so far look promising.