OpenTK normally uses reflection to load bindings, instead of generating
huge constructors. Although reflection is faster on first load (thanks
to reduced JIT overhead), it fails to work correctly with monolinker.
This branch explores the performance of a direct binding.
Implementations may reuse OpenGL context handles that have been
destroyed. If a context is finalized but not Disposed, then OpenTK may
keep a reference to the old context handle, causing a crash when the
same handle is returned for a new context. To fix that, new context
handles will now replace old handles in case of a clash.
GetBoolean, GetInteger6, GetFixedvOES and Delete* are now matched in
the convenience wrapper generator. Methods returning vectors of fixed
size (e.g. 4 ints) are no longer matched.
OpenTK 1.0 and Xamarin Android/iOS do not use strongly-typed enums for
OpenGL ES. Generate overloads with the "All" enum in order to maintain
compatibility.
The static initializer of GetCurrentContext would always default to the
desktop PlatformFactory, which caused problems when trying to run OpenGL
ES code on the desktop. The initializer is now removed and
GetCurrentContext is set in the context constructor, before creating any
contexts.
We should only generate delegates for actual OpenGL entry points, not
for overloaded functions that resolve to the same entry point. This
improves loading speeds and reduces the size of the compiled dll.
The static initializer of GetCurrentContext would always default to the
desktop PlatformFactory, which caused problems when trying to run OpenGL
ES code on the desktop. The initializer is now removed and
GetCurrentContext is set in the context constructor, before creating any
contexts.
GraphicsMode.Default used to be set to
(DisplayDevice.Default.BitsPerPixel, 16, 0, 0, 0, 2, false) for improved
compatibility with older systems. However, this appears to be causing
issues with specific modern GPUs. Switch the default mode to (32, 24, 8)
until a more proper solution can be found.
After the previous commit, several ES 2.0 functions would refer to
enums found in ES 3.0. These enums have been copied to ES 2.0, either
as core enums or as extensions.
ES 3.0 includes ES 2.0 verbatim. We can significantly reduce
duplication by using the same <replace> node for both APIs. Note that
the enumerations must remain separate, as ES 2.0 and 3.0 support
different tokens.
