Sometimes, jokers send us 'mimetypes' like DELETE or
org.webkitgtk.WebKit.custom-pasteboard-data, and gdk_intern_mime_type
will return NULL for such things. Handle that by just closing the fd.
Better than running into an assertion further down.
This is unnecessary.
Worse, it is reentrant and can cause all sorts of avoc when processing
events halfway through initializing the Vulkan context.
It was introduced in commit e11a6a0e68 but back then GTK was barely
branched for GTK4 and Vulkan drivers were very new, and it looks like an
unnecessary workaround.
Testing did not seem to indicate any issues with just removing it, so
here it goes.
Related: #7022
This is unnecessary.
Worse, it is reentrant and causes all sorts of avoc when processing
events halfway through initializing the context.
It only exists because in commit c4244ea1 the win32 Vulkan code was
copy/pasted from another backend.
Related: #7022
It is not necessary.
Worse, it is reentrant and causes all sorts of avoc when processing
events halfway through initializing the context.
It only exists because in commit 3887548 the Wayland Vulkan code
was copy/pasted from X11.
Fixes#7022Fixes#7025
For VK_DEBUG_REPORT_WARNING_BIT_EXT we should always have used
g_warning().
For VK_DEBUG_REPORT_ERROR_BIT_EXT g_critical() is technically the right
choice, but Mesa has been using this flag for normal warnings, so until
that gets fixed, we don't want to throw criticals.
Related: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31292Fixes: !7020
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.
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.
This one got added in 66ba1f76ba but didn’t end
the sentence with a dot, and didn’t have its enum name between parentheses so
that people can debug more easily which error code got generated.
`thread_current_context` might be holding the last reference to
`previous`, in which case `gdk_gl_context_make_current` on the new
context will free `previous`, leaving it a dangling pointer.
Avoid this by making sure to hold a reference.
Fixes: 41cd0c6f "gl: Fix initial EGL context creation on X11"
Resolves: https://gitlab.gnome.org/GNOME/gtk/-/issues/6995
Signed-off-by: Simon McVittie <smcv@debian.org>
Set the alpha channel to "undefined" in this case.
Gimp doesn't seem to like this when opening the image and insists to
doing something with it, that's a bit of a bummer.
But it allows GTK to load RGBx textures.
It seems Mesa doesn't support that yet, but having it doesn't hurt.
And it allows drivers to allocate less memory for the swapchains,
because we don't need all the 4 images we request in minImageCount.
But drivers tend to take that minimum image count as gospel, so we need
to use a higher number to not cause lag in corner cases.
Removed via regex and grep.
The following were intentionally not removed:
- GtkImage:file: (attributes org.gtk.Property.set=gtk_image_set_from_file)
- GtkImage:resource: (attributes org.gtk.Property.set=gtk_image_set_from_resource)
As they have no getter and (setter PROP) without a (getter PROP) crash
gobject-introspection. This is fixed by
ad3118eb51.
The annotations should only be set when the name of the setter or getter
for a property "GtkClassName:prop-name" is not gtk_class_name_g(s)et_property_name.
linear will average all the pixels for the lod, nearest will just pick
one (using the same method as OpenGL/Vulkan, picking bottom right
center).
This doesn't really make linear/nearest filtering work as it should
(because it's still a form of mipmaps), but it has 2 advantages:
1. it gets closer to the desired effect
2. it is a lot faster
Because only 1 pixel is chosen from the original image, instead of
averaging all pixels, a lot less memory needs to be accessed, and
because memory access is the bottleneck for large images, the speedup is
almost linear with the number of pixels not accessed.
And that means that even for lot level 3, aka 1/8th scale, only 1/64 of
the pixels need to be accessed, and everything is 50x faster.
Switching gtk4-demo --run=image_scaling to linear/nearest makes all the
lag go away for me, even with a 64k x 64k image.
We have fast conversion functions, use those directly instead of calling
into gdk_memory_convert().
This is useful because as mentioned before, the main optimization here
is RGB8 => RGBA8 and we have a fastpath for that.
Why do we need this? Because RGB images are provided in RGB format but
GPUs can't handle RGB, only RGBA, so we need to convert.
And we need to do that without allocating too much memory, because
allocating memory is slow. Which means in aprticular we need to do the
conversion after mipmapping, not before (like we were doing).
This allows uploading less memory but requires computing lod levels on
the CPU which is slow because it reads through all of the memory and so
far entirely not optimized.
However, it uses significantly less VRAM.
This is done by adding a gdk_memory_mipmap() function that does this
task.
The texture upload op now accepts a lod level and if that is >0 it uses
gdk_memory_mipmap() on the source texture.
This is just the API. Users will come later.
I considered putting it into gdkmemoryformat.c because it's likely gonna
be the only user and this one function is so little code, but it didn't
fit at all.
So now it's a new file.
Depth of a rendernode should be determined by the textures used and the
compositing colorstate requirements.
Colors influence the colorstate choice, so they indirectly influence the
depth, but they should not influence the depth directly.
Otherwise a single color in a border being rec2100-pq would make us
switch to 16bit float.
Also remove gdk_color_get_depth(), because it was only used here and
because again: Colors should not influence depth decisions.
When prepare_gl fails in the right way (or the wrong way?), we
end up creating the leader window twice, and as a side effect,
creating two instances of the "Virtual core pointer" device, which
is bad news for grabs.
Fixes: #6840
Call wl_surface_offset in end_frame to apply the offset for drag
surfaces. This matches what the GL draw context already does, and
it fixes drag surfaces jumping at the beginning of the drag.
Fixes: #6972
We switched to using the Unicode (UTF-16) versions of the Windows API by
default, so we also obtain the display name in UTF-16 form as well.
This updates the implementation in the Windows backend so that we
properly acquire the names that we need in UTF-16, and then convert the
results to UTF-8, which is what we use in GTK/GLib.
After commit 447bc18c48 EGL on X11 broke.
But the handling of the GL context also was quite awkward because it was
unclear who was responsible for ensuring it got reset.
Change that by making gdk_gl_context_clear_current_if_surface() return
the context (with a reference because it might be the last reference) it
had unset, so that after changing EGL properties the code that caused
the clearing can re-make it current.
This moves the responsibility to the actual code that is dealing with
updating properties and frees the outer layers of code from that task.
And that means the X11 EGL code doesn't need to care and the code in the
Wayland backend that did care can be removed.
Related: !7662Fixes: #6964 on X11
This essentially reverts the changes from
c230546a2c but implies new semantics.
Namely, surface-attached contexts can now be bound to EGL_NO_SURFACE if
the windowing system isn't ready yet.
It is the task of the windowing system to make sure the context is
properly rebound when the contents become available.
We ensure this by checking in begin_frame() if we created the EGL window
and if we did, we make_current(). This works because creating the EGL
window creates the EGL surface and that does a clear_current(), so this
is always going to have the desired effect of re-making the current
context.
It is very convoluted though.
Fixes: #6964
Related: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11784
We do this because:
a) The parent class (GdkGLContext) already stores the paint regions of
previous frames, no need to do the same.
b) The painted region passed to end_frame () includes the backbuffer's
damage region, so it's not really what we want.
This also fixes a leak of cairo_region_t that I introduced by mistake
in !7418
We need to ensure that an EGL surface exists before we call
eglMakeCurrent() with it. Otherwise we might end up binding to
EGL_NO_SURFACE and then never revising that decision.
Which leads to not rendering to the backbuffer, but into the void.
Fixes X11 rendering being black
Fixes#6930
The current resizing implementation in the GDK-Win32 backend is not
telling GDK early enough for Vulkan that a resize in the surface (i.e.
HWND) is done, so that GDK can re-create swapchain in time, which is
apparent on nVidia drivers (and AMD drivers that utilize the mailbox
presentation mode on Windows) when the HWND is being enlarged
interactively.
To work around this, bar a refactor in the Windows resizing/presentation
code, is to call _gdk_surface_update_size() when we really did resize
the HWND when we handle queued resizes via SetWindowsPos().
The existing call in gdksurface-win32.c in
_gdk_win32_surface_compute_size() remains required, otherwise the
surface won't display initially.
Thanks to Benjamin Otte for pointing this possibility out.
We don't need to hardcode all the interface names as string literals,
since they come as part of the wl_interface structs in the protocol
bindings we use.
The easiest things trigger the silliest mistakes. Add tests
for various properties we want our transfer functions to have,
such as:
- be inverse of each other
- stay within the defined ranges
- by symmetric around 0
Set primaries without name if supported, when named primaries are not.
But prefer named primaries if available.
This is just an attempt at defensive coding.
If we get sent primaries with the values as named primaries, treat them
like named primaries.
Fixes colorstate support on Kwin, which never sends named primaries.
If the texture covers all of the black background (like when watching a
1080p stream fullscreen on a 1080p monitor) we don't need a compositor
with single pixel support.
Fixes offloading in Kwin.
There's a ton of error checking happening that we want to do.
Because it turns out it is not really useful to create a subsurface for
the single pixel buffer when we don't even support single pixel buffers.
begin_frame_full does not return a reference, we assume that the
color state is staying alive for the duration of the frame anyway,
so end_frame simply sets priv->color_state to NULL.
We need to round outwards and a 1x1 rectangle with offset 0.5,0.5 should
end up as a 3x3 rectangle with offset 0,0 when rounded, not as a 2x2
rectangle.
We need to round outwards and a 1x1 rectangle with offset 0.5,0.5 should
end up as a 3x3 rectangle with offset 0,0 when rounded, not as a 2x2
rectangle.
The backbuffer's damage region is the region of the backbuffer
that doesn't contain up-to-date contents. This is determined
by the backbuffer's age and previous frame's paint regions.
This enables incremental rendering
Unless there is a very good reason to use memcpy(), don't use it.
Not using it makes the compiler not screw up and waste tons of CPU that
it could have not wasted.
Gets my framerate back from 1250 => 1750 and makes sysprof no longer
report ~40% of render time spent in gsk_gpu_colorize_op().
We know it at begin_frame() time, so if we pass it there instead of
end_frame(), we can use it then to make decisions about opacity.
For example, we could notice that the whole surface is opaque and choose
an RGBx format.
We don't do that yet, but now we could.
The opaque rect from the rendernodes are now used to set the opaque
region in the backend.
This means applications can now set a transparent window background and
make indivual parts of their window opaque.
But because this is a best effort method, it is not guaranteed to
succeed in finding all opaque regions, in particular if the rendernodes
used to build it are not straightforward to analyze.
We are using so many internal extra features that it is no longer a good
idea to use these functions.
And they aren't really used anyway.
These extra features are also constantly in flux and rely on internal
APIs, so exposing them would just cause extra pain.
By using the inlining macro trick, we can work around deprecation
warnings from removing this function as a public API, which will happen
in the next commits.
GLContexts marked as surface_attached are always attached to the surface
in make_current().
Other contexts continue to only get attached to their surface between
begin_frame() and end_frame().
All our renderer use surface-attached contexts now.
Public API only gives out non-surface-attached contexts.
The benefit here is that we can now choose whenever we want to
call make_current() because it will not cause a re-make_current() if we
call it outside vs inside the begin/end_frame() region.
Or in other words: I want to call make_current() before begin_frame()
without a performance penalty, and now I can.
... and pass the opaque region of the node.
We don't do anything with it yet, this is just the plumbing.
The original function still exists, it passes NULL which is the value
for no opaque region at all.
If an image description query is running while the surface gets
destroyed, we were not properly cleaning up, causing the callbacks to be
emitted on freed variables.
We were comparing with destination stride, not with source stride, and
in rare cases when those were different, this would trigger aborts in
the testsuite.
Each time we create a new window, we create a new EGLSurface. Each time
we destroy a window, we failed to destroy the EGLSurface, due to passing
a GdkDisplay instead of a EGLDisplay to eglDestroySurface().
This effectively leaked not only the EGL surface metadata, but also the
associated DMA buffers. For applications where one opens and closes many
windows over the lifetime of the application, and where the application
runs for a long time; for example a terminal emulator server, this
causes a significant memory leak, as the memory will only ever be freed
once once the application process itself exits, if ever.
Fix this passing an actual EGLDisplay instead of an GdkDisplay, to
eglDestroySurface().
This matches what the gpu renderer does when printing
colorstates.
It also avoids it printing "S*RGBA8" for the format and instead prints
"SRGBA8(p)" now.
Converting to and from xyz turns out to be more difficult than
expected, depending on what whitepoint you choose, And different
specs choose different whitepoints, so we can't directly map
css xyz to cicp xyz anyway.
Add a function for converting a single color from one
color state to another. This is a generalization of the
already existing function to convert a GdkRGBA to another
color state.
The outlook for mutter supporting this in GNOME 47 are cloudy,
so lets flip the switch back. You can still set
USE_POINTER_VIEWPORT in the environment to try this code.
When the compositor sends us an image description, we currently happily
reuse it.
However, those image descriptions may contain optional properties that
we do not handle - example: reference white level. So if we were to
reuse that image description, we would set a wrong reference white
level.
To avoid issues like that, never use compositor-provided image
descriptions.
However, query those image descriptions and map them to the closest
GdkColorState, so that we can quickly look up *our* version of that
image description and use that one.
When finalizing a subsurface, we need to make sure it is removed
from the sibling lists in its parent, or bad things will happen.
This should crashes seen in Epiphany nightly.
Fixes: #6891
convert_func2 is a 'from' conversion function, ie it expects to
be passed the target color state. This was wrong both in
gdk_memory_convert and gdk_memory_convert_color_state.
This is widely assumed, but is not guaranteed by Standard C, and is
known to be false on CHERI architectures (which have 64-bit sizes and
128-bit tagged pointers). Add a static assertion to ensure that GTK
will not build on platforms where this assumption does not hold.
As discussed on GNOME/gtk!7510, if GTK switches from gsize to uintptr_t
as its representation of the underlying bits in a pointer, GTK maintainers
would prefer that to be done project-wide so that it's done consistently,
after which this static assertion could be removed.
At the time of writing, GLib makes the same assumption (GNOME/glib#2842),
but GLib contributors are gradually removing it (mostly by replacing gsize
with uintptr_t where a pointer-sized quantity is needed). Finishing
that work in GLib would be a prerequisite for being able to make GTK
work on the affected platforms.
Signed-off-by: Simon McVittie <smcv@debian.org>
Some callers of these functions ask to copy 0 items from a NULL source,
which would be valid if they were copied in a loop (because NULL would
never be dereferenced), but is declared to be undefined behaviour for
Standard C memcpy. Guard the call to memcpy so that we only call it
if we have more than 0 items, and therefore should have a non-NULL
source pointer.
Detected by running a subset of the test suite with
-Dsanitize=address,undefined on x86_64.
Signed-off-by: Simon McVittie <smcv@debian.org>
Unfortunately the format string for a size_t, `%zu`, is not portable
to all Windows compilers, and the appropriate format string for the
fundamental type that implements size_t varies between platforms
(typically `%u` on 32-bit platforms, `%lu` on 64-bit Linux or
`%llu` on 64-bit Windows).
In gtk-demo, cast the number of search results to long, to avoid
breaking up a translatable string.
Elsewhere, use GLib's abstraction for this.
Signed-off-by: Simon McVittie <smcv@debian.org>
Main changes:
1. Avoid invalid writes by not passing pointers to a GArray that
realloc()s its data
2. Use a hash table to store image defs, instead of an array. This
requires a custom hash/equal function
3. Make image desc computation sync, so that setting a cs always
succeeds or always fails and doesn't depend on timing.
4. Add a few debug messages in failure paths. For lack of a category,
they ended up in MISC.
