It turns out that this AeroSnap emulation can really get in the way
as we try to modernize and clean up the codebase, so drop the support,
and so clean up the GDK/Win32 code a bit as a result.
We really want to clean up the event handling and resizing handling a
bit here.
...where we call wglMakeCurrent directly, to inform libepoxy
that the current GL context changed (and thus the current DC
and pixel format may have changed). Skipping the call is not
an issue in practice, since most drivers return the same
pointers regardless of the pixel format (as long as it's an
ICD pixel format instead of the GDI software implementation),
but it's the correct thing to do.
We use it everywhere, so it makes sense to enable it everywhere.
For anyone not in the know, defining COBJMACROS makes Micrsoft headers
for COM objects provide C macros so that instead of having to call
foo->lpVtbl->Release();
to unref a COM object, one can call
IFoo_Release (foo);
Note that thes macros are implemented with inheritance as Release()
is defined on the IUnknown base interface (MS' equivalent to GObject)
and would otherwise require
IUnknown_Release ((IUnknown *) foo);
That line works, too - but it is not necessary.
Existing code assumes displays are new connections and calls
gdk_display_close() on the display when done with whatever it was
doing.
If we return an existing display, that display gets closed...
It's also what the other backends do, including MacOS.
Fixes gsk/misc test.
With the switch to using the glib main context in the clipboard thread,
the clipboard hwnd is no longer used for sending messages.
This means it's not necessary to know it in the main thread.
And that means there's no small window where the clipboard thread spins
up and the window doesn't exist and any copy operation fails.
The main context can be created before spinning up the thread so
that is avoided.
Fixes the gtk/textbuffer test in the testsuite.
Instead of sending windows messages, use the main loop.
This is closer to the expectations of GTK developers and has better
thread safety handling as no HWND is needed as a messaging queue token.
Passing on-stack items to a thread in a function that exits right
after spawning the threads is a bad idea:
By the time the thread starts up and reads the values, the stack might
be in use for other stuff.
So instead of putting the items on the stack, just read them out of the
clipdrop struct.
It seems that NVidia sets PFD_SWAP_EXCHANGE / WGL_SWAP_EXCHANGE_ARB
on pixel formats but doesn't guarantee that the backbuffer age is
constantly 2. My guess is that they use swap exchange only to signal
usage of a flip present method.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/7019
We get to create our GdkKey with a display as a property for free, so
just stuff the default keymap and keymap serial (to track IME state
changes and so) into our GdkWin32Display under an existing sub-struct
that is for holding these items.
On Windows, we really only support a single GdkDisplay, so we can just
make the GdkDisplay that we obtain a property of our GdkDeviceManagerWin32
and GdkWin32Screen objects, and so we can just do away with the global
_gdk_display global variable.
This way, we can also drop the venerable gdkglobals-win32.c source file.
Yay!
Instead, use [Set|Get]WindowLongPtr(), to store and retrieve that
value from the notification window HWND that we are using, as it
is where we are using that value.
