Since the corresponding source files do not include "config.h", and are
not compiled with `GTK_COMPILATION`, they will generate the wrong symbol
exporting under Windows.
Instead of injecting `-fvisibility=hidden` depending on a compiler check
ourselves, let Meson do it for us.
This also avoids us having to filter `-fvisibility=hidden` when reusing
the common compiler flags.
Fix the circular dependency by moving the generated
headers to gdk/version/, and build that directory
first.
Misc other fixes, such as putting the custom targets
as sources, not depedencies, and using the correct
major version in the generator script.
Let's poach the same script used by GLib to avoid having to add all the
version macros by hand every time we increment the GTK version.
This is a work in progress:
- need to rename the GLIB_STATIC_COMPILATION check
- circular dependency: libgtkcss depends on gdkversionmacros.h, but libgdk
depends on libgtkcss
When GDK_DEBUG=no-vsync is on, we might have more than one outstanding
frame. Don't assert when that hapens. Just request a frame callback for
the first and skip the others.
Not all frames get timing info with GDK_DEBUG=no-vsync, so make sure
that even when we render tons of frames, the one frame that does get
timing info is still there when the timing info arrives.
I set it to 128 from 16 now.
This is roughly good enough to go to 5000fps from on a 60Hz monitor.
...when we are using wglChoosePixelFormatARHB(). This ensures that we
hvae a HDC with a pixel format that will really support alpha bits, as
we did for the traditional ChoosePixelFormat().
Thanks to Patrick Zacharias for testing and pointing things out.
We were sending random junk to ChoosePixelFormat().
Also assert that we don't overflow the array. That might be usefu to
know if we carelessly add attributes later.
... for creating the actual WGL contexts, so that we can cut down on the
number of times where we need to create the base, legacy WGL contexts in
order to create the WGL contexts with attributes. We could just use the
dummy context that we have to make it current to create the needed
WGL contexts.
If we are querying the best supported pixel format for our HDC via
wglChoosePixelFormatARB() (i.e. we have the WGL_ARB_pixel_format extension),
it may return a pixel format that is different from the pixel format that we
used for the dummy context that we have setup, in order to, well, run
wglChoosePixelFormatARB(), which sadly requires a WGL context (HGLRC) to be
current in order to use it, which means the dummy HDC already has a pixel
format that has been set (notice that each HDC is only allowed to have its
pixel format to be set *once*). This is notably the case on Intel display
drivers.
Since we are emulating surfaceless GL contexts, we are using the dummy GL
context (and thus dummy HDC that is derived from the notification HWND used in
GdkWin32Display) for doing that, we would get into trouble if th actual HDC
from the GdkWin32Surface has a different pixel format set.
So, as a result, in order to fix this situation, we do the following:
* Create yet another dummy HWND in order to grab the HDC to query for the
capabilities the GL drivers support, and to call wglChoosePixelFormatARB() as
appropriate (or ChoosePixelFormat()) for the final pixel format that we use.
* Ditch the dummy GL context, HDC and HWND after obtaining the pixel format.
* Then set the final pixel format that we obtained onto the HDC that is derived
from the HWND used in GdkWin32Display for notifications, which will become our
new dummy HDC.
* Create a new dummy HGLRC for use with the new dummy HDC to emulate surfaceless
GL support.
We are currently using g_clear_pointer() on the intermediate WGL contexts
(HGLRC)'s that we need to create in the way, which means that we need to ensure
that the correct calling convention for wglDeleteContext() is being applied.
To be absolutely safe about it, use the gdk_win32_private_wglDeleteContext()
calls, which will in turn call wglDeleteContext() directly from opengl32.dll
(using the OpenGL headers from the Windows SDK) instead of going via libepoxy,
which will assure us that the correct calling convention is applied.
Fixes issue #5808.
Our notify tests would fall over if there was
a duplicate enum value (within the first 10 values).
Make it handle that, by skipping the duplicate value.
It turns out that the old behavior of GTK_ALIGN_BASELINE
was actually used in libadwaita, so bring it back, and
introduce a new GtkAlign value for the new behavior.
Allow control-clicks on some fields to bring up
a more specific UI. This functionality is also
available via Ctrl-E and the context menu.
At this point, it can edit colors, fonts and
files in some places, as well as a few enums.
