There is nothing really special about this code, its just a helper for
uploading pixel data to opengl, and we're not really in the business
of doing opengl-specific helper functions.
Do custom uploads rather than using gdk_cairo_surface_upload_to_gl(),
because this way we avoids a roundtrip (memcpy and possibly conversion)
to the cairo image surface format.
The gdk-pixbuf non-rgba format can be directly uploaded without
conversion.
The rgba format needs alpha premultiplication though, which is not
supported by GL during upload.
GLES doesn't support the GL_BGRA + GL_UNSIGNED_INT_24_8 hack that
we use on desktop OpenGL to upload textures directly in the cairo
pixel format. This adds the required conversions to all the places
that currently need it.
We also add a data_format to the internal gdk_gl_context_upload_texture()
function to make it clearer what the format are. Currently it is always
the cairo image surface format, but eventually we want to support other
formats so that we can avoid some of the unnecessary conversions we do.
Also, the current gdk_gl_context_upload_texture() code always converts
to a cairo format and uploads that like we did before. Later commits
will allow this to use other upload formats that gl supports to avoid
conversions.
This is the default OpenGL format, and in fact the only pixel format
that GLES supports uploading as. Actually, the premultiplied part is
really just about how we use the textures, but all textures in GTK
are premultiplied.
Most of the surface api we have in the Wayland backend
only makes sense for toplevels, so reshuffle things to
take a GdkToplevel instead of a GdkSurface.
Update all callers and the docs.
We must wl_surface.commit after xdg_surface.ack_configure to make it
have an effect. We failed to do so when a configure event didn't result
in new updates, so make sure we fall back on an simple
wl_surface.commit if there was no new actual frame painted.
Closes: #2910
In order to make the cairo renderer/context behave more similar to how
the OpenGL and Vulkan renderer/context behaves, request a frame callback
and commit in the end frame vfunc.
This means the end frame vfunc in cairo does
* attach buffer
* request frame callback
* sync surface state
* commit
Where as e.g. the OpenGL version of the same flow does
* attach buffer
* request frame callback
* sync surface state
* eglSwapBuffers()
where eglSwapBuffers() indirectly calls wl_surface_commit().
Since the changes to GDK to use surface subtypes, CSD windows were
broken because we did not set the window styles properly. Fix this by
first acquiring whether decorations are used by the GtkWindow, and based
on that result we set the decorations that we want to use accordingly
and so apply them.
Thanks to Matt Jakeman for investigating into the issue and providing
pointers to a proposed fix.
Fixes issue #3157, besides the part where window sizes are not correct
since that is likely caused a separate issue.
Don't pass 0x0 as size when calling gdk_surface_new().
The Wayland backend takes us literally, and we end
up with a surface that (temporarily) has these
dimensions, confusing other APIs that we pass the
size to, such as Vulkan.
We end up with a surface that has size 0x0 at the
time we create the Vulkan context, and that is a
size that Vulkan doesn't like, so ensure we request
at least 1x1.
Fixes: #3147
When using the gdk_display_close(), the handle to the Wayland compositor was not released. This could cause the consumption of all available handles, preventing other processes from accessing the display.
Fixing this by calling wl_display_disconnect() when releasing the GdkWaylandDisplay object.
Signed-off-by: Julien Ropé <jrope@redhat.com>
We want to ensure that the pointer position is reflected
when widget geometry changes, so add a function that tells
GDK "please create a motion event at the current position
on this surface, if one doesn't happen already".
Handle both these settings, and the older settings-daemon ones for
backwards compatibility. The keys are already checked for existence
in the schema, so it will just use the existing ones.
Prefer this location, but also look for the old location in
settings-daemon for backwards compatibility. This applies to both
direct settings lookups and via the settings portal.
