eglGetProcAddress cannot be used to retrieve
entry points of core functions. Instead, we
use [DllImport] for core functions and function
pointers for extension functions.
Squashed commit of the following:
commit 0b84aa6ef78dfa3600b81fc412eb192f2a87e40c
Author: thefiddler <stapostol@gmail.com>
Date: Sat Mar 15 02:24:58 2014 +0100
[Examples] Rolled back changes to Example browser
commit 1acfbaac3d17184debdbbe872c58ac07d1b37c0a
Author: thefiddler <stapostol@gmail.com>
Date: Sat Mar 15 02:20:57 2014 +0100
[Examples] Rolled back WinForms example
commit 835d9d6035a890bd3426566929fbfd25c493eca0
Author: thefiddler <stapostol@gmail.com>
Date: Sat Mar 15 01:15:01 2014 +0100
[Examples] Rolled back erroneous GLControl mods
commit 056418014f0e835e83fb85b54b8749519a555364
Author: thefiddler <stapostol@gmail.com>
Date: Fri Mar 14 23:11:11 2014 +0100
[Rewrite] Remove calli prototypes
When a function is called indirectly via a function pointer, its
prototype is not required (the prototype is added as a callsite at the
calli invocation.) Removing these prototypes reduces binary size by
roughly 400KB.
commit 353a16ec2836c597150d2fab28581e7c264b2b39
Author: thefiddler <stapostol@gmail.com>
Date: Fri Mar 14 22:31:25 2014 +0100
[Rewrite] Call DllImports directly
When a function does not have an allocated slot (i.e. slot = -1), then
we will call its DllImport signature directly.
commit 9a5313e4b7afb10b698d255e4b5637887bf71cf3
Author: thefiddler <stapostol@gmail.com>
Date: Fri Mar 14 22:30:04 2014 +0100
[Bind] Do not allocate slots for DllImports
commit 6ac5342409363cac0e59f9dc669948b319bd20a9
Author: thefiddler <stapostol@gmail.com>
Date: Fri Mar 14 22:29:07 2014 +0100
[Bind] Added option to use DllImports
This is necessary for the core functionality of OpenGL ES, where
eglGetProcAddress returns null or garbage (the latter on Android.)
IGraphicsContext.VSync property is obsolete, but we have to call it in
the GraphicsContext.VSync implementation, so disable the obsolete
warning for this one use.
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.
