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.
Tuck the _win32_device_manager global variable into GdkWin32Display, and
drop the global variables that have to do with GdkDeviceManagerWin32.
Also improve how we query the WinPointer APIs from user32.dll, so that
we are sure that it is done once and only once.
Tuck the GdkWin32Clipdrop that we create in our GdkWin32Display, and
tuck the other associated global variables into GdkWin32ClipDrop and
GdkWin32Drag, as appropriate.
Also, since we are already registering "GDK_WORKER_THREAD_WAKEUP" as our
custom message to look for in our DND/clipboard ops, only register it
once, not twice, as it's not really necessary to do so since
RegisterWindowMessage() returns the same value for the same identifier
that is being used.,
Instead, record the current thread in the GdkDisplay, under a structure
for DND items, which will hold other relevant Windows Clipbord/DND global
variables.
Add a new function in gdkdrag-win32.c to check whether the current
thread is (or is not) equivilant to the thread that is initiated when
the GdkDisplay is initialized (which also returns true if there is no
GdkDisplay that is associated with the GdkDrag in question).
Fold these items into GdkWin32Display, and also fold gdkproperty-win32.c
and gdkwin32langnoticiation.[c|h] into gdkdisplay-win32.c|h].
This way, we get rid of few more global variables, and these items
should have been initialized (and registered with the system) when we
open a GdkWin32Display anyways.
Use the gdk_win32_surface_parent_class that is given to us by
G_DEFINE_TYPE() instead of using a global variable to store up the
parent class of GdkWin32Surface.
We want to make the distinction between GdkSurface's and native Windows
HWNDs clear, and we don't want to confuse between GdkSurface's and
Vulkan surfaces.
In order to help us in our refactoring, make the distinction between Gdk
surfaces and native Win32 HWND clearer in terms of the variables that we
used, and in the comments in the code.
Also, group forward function prototype declarations in one place, and
drop some unneeded items in gdkprivate-win32.h to fold them into
gdksurface-win32.c, as they are only used there.
Only initialize the Vulkan or EGL parts where possible.
When dmabufs or dmabuf formats are actually used, we still
initialize fully by creating both a Vulkan and EGL downloader.
This shortens the time to first commit from 149ms to 108ms.
This takes the `position` property and ensures children are sorted by
it, splits children by `pack-type` (also reversing the order of `end`
children), and handles children with `type="center"`.
If either a center child or end children exist, then the `GtkBox` is
converted to a `GtkCenterBox`, with `start-widget`/`end-widget` being a
nested `GtkBox` with the relevant children.
The splitting does cause some non-`object` children to sort differently
(hence the change to `office-runner.expected`.)
Just use two individual fields, so we can track if we've already
created each one. This also matches the individual fields we have
for the dmabuf formats.
And change preference order of downloaders
Previously, our order was mmap > vulkan > egl.
But depending on the hw (discrete vs integrated gpu), mmap
can be catastrophically slower (on the order of 20ms vs 1.5s).
So, change the order to egl > vulkan > mmap.
Note that this currently has less effect than we'd like to,
since we don't let the downloaders claim linear formats.
Some nodes like `GtkBox` need to process removed-in-GTK4 attributes to
correctly convert their contents. If the node children are processed
first, then those attributes are removed prematurely.
