Don't filter window messages passed to our window (see
http://blogs.msdn.com/b/oldnewthing/archive/2005/02/09/369804.aspx).
Additionally, return the correct values for all messages we are actually
handling and clean up unmanaged memory after we are done with the
window.
Instead of combining PeekMessage+GetMessage, we can simply call
PeekMessage(Remove) to achieve the same effect. This also allows us to
remove the IsIdle property, which is no longer used anywhere.
The temporary context is now retained until the actual context has been
constructed. If we don't do this, then WGL_ARB_create_context may fail
to work correctly on specific GPUs (e.g. Intel). This may affect issue
#19.
The correct way to query number of available pixel formats is to use
Wgl.Arb.GetPixelFormatAttrib(NumberPixelFormatsArb), not
Wgl.Arb.ChoosePixelFormats. This fixes an issue where Intel drivers
would fail to report any pixel formats in GetModesARB, even when
WGL_ARB_pixel_format is supported.
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.
Misbehaving clients that shall not be named here may call
GameWindow.Close() inside the GameWindow.Closing event. This causes
recursion in SDL2, crashing the application.
This patch adds a guard to protect against recursion when calling
GameWindow.Close().
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.
Tools now go to the Binaries/Tools/[Debug|Release] directory. OpenTK
remains at BInaries/OpenTK/[Debug|Release].
Mono.Cecil and IKVM now reside under the Dependencies/managed/
directory.
Instead of modifying the name of an OpenGL symbol on the managed side,
before copying it to the unmanaged side, we perform the modification
directly on the unmanaged side. This reduces the total amount of
allocations in OpenTK by ~30% (673496 bytes in 10750 objects compared
to 930272 bytes in 15243 objects before this modification.)
WS_CLIPCHILDREN and WS_CLIPSIBLINGS appear to cause flickering on
specific video cards. OpenGL appears to work correctly without these, so
we'll disable them to return to OpenTK 1.0 behavior.
It is now possible to indicate that an application is not DPI-aware. In
that case, OpenTK will let the operating system handle DPI scaling. This
results in worse visuals (pixel doubling) but allows non DPI-aware
applications to continue working.
It appears that calli callsites cannot be decorated with the
“platformapi” calling convention like DllImport signatures can. This is
problematic since Windows uses stdcall by default and most other
platforms use cdecl.
There are three approaches to this issue, without going back to
delegate calls: (a) generate an unmanaged thunk that cleans up the
stack after a GL call; (b) use libFFI; (c) use cdecl *or* stdcall
everywhere and hope that the runtime can cope.
.Net 2.0 can detect and fix stdcall functions invoked through a cdecl
callsite. .Net 4.0 adds a configuration option to enable or disable
this fixup (faster p/invoke if disabled) and raise a MDA exception when
this condition is detected. (This affects x86 only.)
Mono appears to be able to cope with cdecl functions invoked through a
stdcall callsite.
More testing is required.
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.
By using untyped integers instead of typed integers in the unmanaged
callsites, we allow monolinker to keep the exact set of enums that are
used by the user. Without this, we’d have to keep every single enum in
place to avoid missing type exceptions.
This does not affect the public signatures or the generated code in any
way.
This includes arrays of primitives and arrays of generics. Our code is
similar to the code generated by the Mono C# compiler for the "fixed"
construct. The .Net compiler produces slightly different code (two local
variables instead of one) - more research is required.
Default results in a managed calling convention which does not generate
unmanaged thunking code for parameter marshaling.
System.Runtime.InteropServices.CallingConvention.Winapi appears to
correspond to StdCall for calli callsites (this might be different for
pinvoke, which supports an unmanaged "platformapi" calling convention.)
Needs more testing to prove this is doing the right thing on non-Windows
platforms.
WGL was autogenerated a few years ago but never touched after that.
Since we use a tiny fraction of all available methods, it makes sense to
remove the unused ones. This reduces dll size and improves startup
times.
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.
.Net will happily execute a calli with a generic return type, whereas
Mono will refuse to. Mono is probably doing the right thing here. Fixed
by resolving the generic return into a concrete type.
