This protects against a potential denial-of-service issue during mode
selection, where the platform backend will try to reduce AA level until
a supported mode is found.
When combining OpenTK with a third-party OpenGL toolkit, it is now
possible to implement a suitable GetAddress() and GetCurrentContext()
implementation in terms of the third-party toolkit. If no
implementation is specified, then OpenTK will try to guess the most
suitable implementation within its own platform backends.
If no custom implementation is defined, and if no suitable
implementation can be found, then OpenTK will throw a
PlatformNotSupportedException. If a suitable implementation is found or
defined, then OpenTK will attempt to load OpenGL entry points using
that implementation.
In this case third-party toolkit remains solely responsible for
managing its context via its MakeCurrent(), SwapBuffers(), etc
implementations.
On many/most platforms, GraphicsContexts can only be released by the
thread where they are current. This means that the user must call
GraphicsContext.Dispose() or risk a resource leak.
Since we cannot release contexts on the finalizer thread, we should keep
strong references, instead of weak references, until the user explicitly
calls Dispose().
This patch fixes issues with SDL2 crashing when running the MonoGame
WindowsGL test suite.
Several projects are still using the last svn revision from the
sourceforge repository (r3127). These overloads provide an upgrade path
from r3127 to OpenTK 1.1.
The Mono 2.10 compiler fails when compiling extern methods that are not
marked as DllImport. We fix that by adding a method body that throws a
NotImplementedException instead.
Additionally, MonoDevelop 2.8 cannot open sln files with ToolsVersion 12.
The fix is to change ToolsVersion to 11.
We should be able to use static pinvokes on platforms that do not
provide or require extensions and calli instructions on platforms with
extension APIs. This dinstiction will be implemented as a parameter in
the rewriter.
The rewriter will patch the body of methods marked with [AutoGenerated].
Methods that are implemented manually (e.g. various math helper
overloads) should avoid this attribute.
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.
