For now, this is just doing the code reshuffling. The environment
variable still expects you to set
GSK_RENDERER=ngl
gsk_ngl_renderer_new is still around, deprecated, and returns
a renderer that fails to realize.
The gsk/gl/gskglrenderer.h is still installed, but including it
triggers a deprecation warning.
This is useful for testing of repeat nodes - both performance
and conformance, and potentially even driver issues with GL_REPEAT.
We have code for manual repeating anyway, so adding a flag to force
always using it is easy.
The last part of logic in gtk_scrolled_window_measure () that accounted
for scrollbars was handling the hscrollbar first, and vscrollbar second.
For each of them, it looked at the orientation we're being measured in,
and either added or MAX'ed scrollbar's size request into ours (or not,
depending on scrollbar policy and whether overlay scrolling is used).
In case of GTK_ORIENTATION_HORIZONTAL, this resulted in
// MAX in hscrollbar width.
minimum_req = MAX (minimum_req, min_scrollbar_width + sborder.left + sborder.right);
// Add in vscrollbar width.
minimum_req += min_scrollbar_width;
whereas for GTK_ORIENTATION_VERTICAL, it was
// Add in hscrollbar height.
minimum_req += min_scrollbar_height;
// MAX in vscrollbar height.
minimum_req = MAX (minimum_req, min_scrollbar_height + sborder.top + sborder.bottom);
The former is correct and the latter is wrong: we should be adding the
size requests of the scrollbars together, and MAX'ing them with the
content size request.
Fix this by refactoring the logic to first handle the MAX'ing, and then
the addition.
This fixes the following criticals:
Gtk-CRITICAL **: 17:26:51.406: Allocation height too small. Tried to allocate 15x31, but GtkScrollbar 0x2a00fac0 needs at least 15x46.
that were happening when all of:
- scrollbar policy was set to ALWAYS,
- overlay scrolling was disabled,
- the scrollable child was really small.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
It is possible that the window gets unrealized while a handle to its
surface is exported. This, naturally, invalidates the handle, so there
is nothing left to unexport. We should just note that and do nothing,
rather than crashing.
Fixes a crash when a portal-backed file dialog parented to a window is
closed after the window it was parented to.
Reported-by: Ivan Molodetskikh <yalterz@gmail.com>
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
When setting a new paintable, we don't need to queue_resize() when it's
the same size as the old paintable.
This is especially useful when pictures are used in a listview or
gridview and different rows display images of the same size.
It is useful to track down mysterious crashes in ci, but it causes
sporadic test failures, so disable it for now, until we have another
mysterious crash.
Upon joining the a11y tree. And do so recursively, as long as the parent
is also not a widget.
As for the explanation, please grab a mug of your favorite drink. It's
a little complicated.
GTK realizes AT contexts in 3 situations:
1. When it's a toplevel, it's realized unconditionally
2. When the widget is focused
3. When the accessible is appended to a realized parent
Most importantly, GTK lazily realizes accessibles, and does not realize
child accessibles recursively.
Clearly, conditions 1 and 2 only ever happen for GtkWidgets, which are
accessible objects themselves. These two conditions will handle the vast
majority of cases of apps and platform libraries.
However, there are non-widget accessibles out there. GTK itself offers a
non-widget accessible implementation - GtkAtspiSocket - which is used by
WebKitGTK.
Now, let's look at WebKitGTK use case. It'll demonstrate the problem
nicely.
WebKitGTK creates the GtkAtspiSocket object *after* loading most of the
page. At this point, there are 2 possibilities:
1. The web view widget is focused. In this case, the AT context of the
web view is realized, and GTK will realize the GtkAtspiSocket when
it is added to the a11y tree (condition 3 above).
2. The web view widget is *not* focused. At some point the user focuses
the web view, and GTK will realize the AT context of the web view.
But remember, GTK does not realize child accessibles! That means
GtkAtspiSocket won't be realized.
This example demonstrates a general problem with non-widget accessibles:
non-widget accessibles cannot trigger conditions 1 and 2, so they're
never realized. The only way they're realized in if they happen to be
added to an already realized accessible (condition 3).
To fix that, the following is proposed: always realize non-widget
accessibles, and also of their non-widget accessible parents. This is
not ideal, of course, as it might generate some D-Bus chattery, but GTK
does not have enough information to realize these objects at more
appropriate times.
Move the code that realizes an AT context if the parent is realized,
into to a separate function. This will make the next patch easier to
read.
No functional changes.
... and print if a format is advertised.
We now use the same style of message and use the term "advertise" for
formats that will be available via GdkDisplay::dmabuf-formats and
"supports" for formats the backend pretends it can handle but don't
want to advertise them.
Instead of only printing the advertised dmabuf formats, print all
supported ones. This is now useful information because we will try to
use them when downloading.
Fixes me looking like I don't know what I'm talking about on IRC when
claiming that llvmpipe can't do dmabufs, because it only supports linear
ones and we didn't print those.
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.
We don't need our own mechanism for device selection; mesa has a
Vulkan layer that works perfectly fine for this purpose; just set
MESA_VK_DEVICE_SELECT.
If that flag is set, we keep the bounds of the original node when
rendering the modified node.
Gets around the replay test having to draw a transparent color node to
ensure the same bounds.
This reverts commit fd02afa2e4.
We don't want to remove the GL renderer from our tools yet, because we
use those tools for manual testing and having it available is useful.
In particular, reinstate the GL renderer for rendernode-tool benchmark.
Treat external as the normal case, and only try importing dmabufs
as non-external images if their format is on the internal formats
list.
Also add internal linear formats to the internal formats list.
This fixes an issue where AR24:0 dmabufs were imported as external
textures, causing some of the compare tests to fail.
Make this function return whether it was successful, and only emit
a debug message if we succeeded. In particular, make it return FALSE
if the dmabuf format is not linear.
The current context might be the last reference to the context, which
would make it go away when the renderer calls make_current().
See commit 0fa2ae48d4 for a similar case.
When we use download in the middle of an upload operation (or the
other way around), we may end up making a different GL context
current. The downloader code is reponsible for reestablishing
the previous context when it is done. The old GL renderer was
doing that, NGL wasn't, until now.
For dmabufs, the format is not an exact description of the data, it only
gives the closest memory format for a given fourcc.
This of course means that multiple different fourccs may report the same
format.
So when deciding if we need to copy the image to get the right data to
download, we need to check if the fourcc is correct, not if the format
is.
Related: #7046
When we want to download a dmabuf, we want to download the actual
dmabuf.
If we just grab the cached image and use that, we might get the
(reuploaded) copy of the dmabuf. This happens when this renderer
doesn't support downloading this dmabuf but has used it before.
Worse, this is a reentrancy issue, where this renderer is trying to
render the dmabuf and has already scheduled the upload but the upload
has not finished. We will then download from an empty image, which is
very wrong.
The way to check that we have the actual dmabuf is a bit brittle, but it
should work.
Fixes#7046
I've seen valgrind complain about external_only being uninitialized
after the call, when using llvmpipe. Better be safe than sorry, and
initialize these arrays.
Compositors don't guarantee that there's any physical devices
around to correspond to the input capabilities.
This was found running the tests against mutter headless.
Previously it was unclear why passing an input stream would crash a video,
unless you went into the source and read it.
This adds a clarifying message that only file based media files are supported.
The clip might be different from the scissor due to incompatible
intersections.
But the resulting intersection might be fully clipped, so we should
consider it.
Testsuite with longer explanation attached.
Fixes#7044
Doing otherwise risks that the focus is moved back to the entry,
causing everything to be selected, and then replaced by the Emoji
we insert. Which is not the desired effect!
When picking a cursor image size for a given size, look for sizes
that do better when scaled by the viewporter:
- exact size
- twice the size
- closest larger size
- closest size
This was a thinko in 403da9a2d5. We have the cursor
image in device pixels, but we still need to apply the viewporter
to inform the compositor about the desired pointer size in
application pixels.
Instead of using glBuffer(Sub)Data() every time we set new globals, fill
a single buffer with all the globals and use glBindBufferRange() on that
buffer to set the current globals.
Stop using a viewporter to scale cursors. Instead, just pass
the surface scale to the cursor loading code, and take the
buffer dimensions and hotspot that it returns, unchanged.
This avoids problems with cursor themes like Breeze, where
buffer dimensions are different from the nominal cursor size.
Make the cursor loading code take a floating point scale,
and return the closest sized cursor that it can find.
This resolves issue with labels of model buttons being set to
presentation a11y role but still have a11y label.
See: b7e5a79468/gtk/gtkmodelbutton.c (L1539)
It works, now and is faster than the old GL downloader.
Playing the Barbie trailer @ 4k with hardware decoding but the Cairo
renderer on a 4k screen:
downloader windowed fullscreen
GL 12fps 19fps
NGL 16fps 29fps
Vulkan 16fps 29fps
no dmabufs 12fps 19fps
For some formats, we could not download the dmabuf directly - in
particular YUV formats.
For those, do a copy on the GPU into the correct format.
While we're at it, also check the desired format and colorstate and if
they don't match, do the conversion on the GPU instead of using
gdk_memory_convert().
Reserve the CPU conversion for situations where the GPU doesn't support
the final format - like for example G8A8 (or often also RGB16).
Make gsk_gpu_cache_cache_texture_image() API safer by accepting all
color states as input and just not caching the images for colorstates we
don't care about.
Instead of passing down the depth and extracting format/srgb from it at
the end, extract format/srgb in the nodeprocessor and pass it down.
This allows creating offscreens for weirder formats in the future.
... and use it for the dmabuf downloader
Splits the download op into 2 separate ops: One for downloading textures
and one for downloading into preallocated memory.
The download into memory is the fallback for the texture downloading op,
so they need to share code.
But keeping them separate ensures that the different codepaths for
dmabuf download and render_texture() don't get mixed up in weird ways
that potentially call into each other.
By passing the emory down into the op we can also avoid an extra memcpy
which can lead to quite large speedups for big textures.
We want to share the texture download function with the renderers, so
they can download textures without needing to wrap them in a
GdkGLTexture.
Move it into gdkglcontext.c for that purpose.
This is similar to the other tab-behavior properties, and allows
to control how the tabbing behaves in context of a GtkListBox.
It allows to make gnome-initial-setup#216 history, for example.
Due to a Mesa bug, RGBA16 images aren't properly handled sometimes and
can cause random failures.
In this case, generating the modified reference images for the tests
fails.
Fixes CI breakage.
Related: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11750
The image is already associated with the original texture, the
one that the download op creates is purely to hand it to the
downloader, it should not be associated with the image.
This makes the ngl downloader work as well as the vulkan one
(ie rgba dmabufs work, yuv ones don't, since we don't convert
them).
We keep a pointer to the GdkDrop object without a reference, and
then it dies on us. Be more careful, and clean up the dnd section
when the we drop object goes away.
Fixes: #7026
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
When the text is rtl, pango will put the text at the right end of
its given width, causing the logical.x to be big, and in turn, our
computed position to be negative. If we don't allow that, centered
text will end up at the right side if it is rtl.
Fixes: #6836
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.
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.
In the colorize and texture ops, print the tex rect. This is useful
because when adding new features with textures (like atlas usage), these
are the ops that I use for testing.
Instead of recreating frames from scratch every time, use an existing one.
This ensures that renderers don't need to recreate GPU resources every
time (like buffers and everything else that frames manage). It also
speeds up occasional render_texture() calls in default renderers.
This speeds up in particular the Vulkan renderer.
This is useful because cleaning up will do the final copies of texture
data.
It also means we use less memory, as we're going to release images that
were used in ops.
If no ops are recorded, then we don't need to wait for any ops to
finish.
Also fix the initial fence creation on Vulkan - we no longer need to
create it fixed because of the random cleanup() call at startup does no
longer happen.
There was a typo ‘phases happens’, but also some spurious whitespace and
slightly odd-sounding use of ‘we’ so I changed it to be phrased
passively.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
The Flatpak portal (and so far all other portals) live in the session
bus, not in the a11y bus.
Use the session bus to get the Flatpak portal version. Avoid too many
synchronous D-Bus calls on startup by using g_once_init_* helpers.
In the rare situation (read: I triggered it with obscure hacks) where no
ops are emitted, we could end up pointing into invalid memory and
crashing.
Don't do that.
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.
g_file_monitor_directory () can fail. We're ignoring the actual error
by passing NULL for the error argument, but we shouldn't be trying to
connect to a signal on the NULL value that gets returned on error.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
gtk_file_chooser_get_current_folder () is transfer full, while
g_list_store_append () is transfer none.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
`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>
Opaque textures don't clamp to transparent but instead to black.
We didn't consider this, so we were blurring their edges into blackness
not into transparency.
Fix this by adding the GSK_GPU_AS_IMAGE_SAMPLED_OUT_OF_BOUNDS flag
and respecting it in the implementation that uses it.
Test included.
Fixes#6980
Swizzling is not respected for blitting.
See commit 058252e895 for the same change in Vulkan.
Apparently that never made it to ngl.
The next commit will have a test for this.
I've had a need for flags for the get_as_image() call but so far have
been able to work around it. But now it seems I might finally need it.
This just introduces the flags but doesn't add any.
Related: #6980
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.
This variant takes the color_states, instead of computing it
anew from the ccs and the color state of the color. This will
be used to pull this work out of the loop in add_glyph_node.
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.
Add buttons for loading the Portland Rose, and a nameless large
png. Make them load the texture in a thread, to demonstrate better
handling of large images.
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.
rgba(from @foo ...) would crash if @foo was not a named color.
Handle it as we do elsewhere, by returning NULL from resolve().
Test included.
Fixes: #6985
If the popover isn't visible, no need to do any extra
'cascade' work. This also helps to avoid running into
trouble during finalization when the parents are already
gone.
wglGetExtensionsStringARB takes an HDC argument even though it
checks extensions for the current context. This was done for future
extensibility. From [1]:
> Should this function take an hdc? It seems like a good idea. At
> some point MS may want to incorporate this into OpenGL32. If they
> do this and and they want to support more than one ICD, then an HDC
> would be needed.
Currently the HDC argument is unused, but still wglGetExtensionsStringARB()
is required to check if HDC is valid:
> If <hdc> does not indicate a valid device context then the function
> fails and the error ERROR_DC_NOT_FOUND is generated. If the function
> fails, the return value is NULL. To get extended error information,
> call GetLastError.
So wglGetExtensionsStringARB fails if we pass NULL. Here we can pass any
valid HDC, like for example the screen DC returned by GetDC(NULL), but
probably using wglGetCurrentDC() makes most sense.
Reference:
[1] - https://registry.khronos.org/OpenGL/extensions/ARB/WGL_ARB_extensions_string.txt
If all four of the random colours have alpha channel exactly 0.0,
then the computed premultiplied average will also be zero.
Normalize the expected colour to (0,0,0,0) rather than (NaN,NaN,NaN,0).
Resolves: https://gitlab.gnome.org/GNOME/gtk/-/issues/6977
Signed-off-by: Simon McVittie <smcv@debian.org>
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.
We want to use the display's context on the resulting texture,
but we do not want to use it for the stufff we need to do while
exporting - most importantly the GLsync.
Fixes#6976
It seems we can get spurious de-registrations, so let's avoid spamming
the logs, and also avoid crashes from applications whose maintainer
decided to turn all critical warnings into assertions.
Previously it ended on the immediate parent of the lowest level popover,
which was not good, as it very likely was some even already hidden widget, or
at least, the a11y machinery thought so.
When selecting an emoji in the recent section, there is no need
to add it to the recent section again. This avoids a sequence of
unfortunate events, where we reconstruct the entire recent section,
thereby removing the focus child, causing the focus to revert to
the entry, causing the entry to select the entire text. In the
case of Ctrl-clicking to select multiple Emoji, the effect is that
the section Emoji will replace the entire entry text, which is
suprising and unintended.
Fixes: #6336
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
Keep a hard copy of the widget event controllers to handle state
changes across, and check for controllers that might have been detached.
This makes us:
- Tiptoe over controllers that might have been removed directly or
indirectly as a result of a signal emitted here, which is great and
fixes possible crashes.
- Ignore new controllers that might have been added in the handling
of these signals, which is fair enough since these controllers did
not handle any input related to the state change.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/6924
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
On GTK's official upstream CI, all Linux runners are meant to have
/dev/udmabuf available, so this should pass. On developer machines or
downstream build environments, this can't be guaranteed (not all kernel
configurations offer that device, and on those that do, an autobuilder
might not have access to it) so make it possible to skip this with
`--no-suite=needs-udmabuf`.
Any future tests that rely on /dev/udmabuf (as opposed to using it for
optional better coverage if available, like replay-node does) can be
aded to the same suite.
Signed-off-by: Simon McVittie <smcv@debian.org>
This function is used to sort a GPtrArray of "pointers" which are
actually GINT_TO_POINTER (id), so a and b are pointers to pointer-sized
quantities.
Previously it was assuming that both were int-sized quantities,
dereferencing them to get the first sizeof(int) bytes, and then
redundantly casting those bytes to int. However, on a 64-bit big-endian
platform, the first few bytes of a larger-than-int quantity are the
most significant part, in practice 0, causing an out-of-bounds array
access and a crash. This was visible in the
`gtk:css / parser variables.css` automated test.
Bug-Debian: https://bugs.debian.org/1079546
Signed-off-by: Simon McVittie <smcv@debian.org>
Previously this code assumed that if we have an int stored in a hash
table via GINT_TO_POINTER, we can retrieve the pointer value and treat
its first sizeof(int) bytes as an item to append to a GArray of int.
However, on a 64-bit big-endian system, the first sizeof(int)
bytes of the pointer will be zero, which is not a valid ID for a
GtkCssCustomPropertyPool, causing an out-of-bounds array access and
a crash. This was visible in the `gtk:css / style` automated test.
Bug-Debian: https://bugs.debian.org/1079546
Signed-off-by: Simon McVittie <smcv@debian.org>
This more closely matches the spec. This is an API break, however the
atspi backend already assumed that this was a list, and would throw
criticals whenever this relation was set. Therefore it can be assumed
that this relation was not previously in active use.
Event listeners can register themselves multiple times, and deregister
themselves as well. We need to remove an event listener only if it
dropped all its events.
Assistive technologies using AT-SPI typically register themselves on the
accessibility bus through the org.a11y.atspi.Registry.RegisterEvent
method, which will emit the EventListenerRegistered signal. We can use
that signal (and its corresponding EventListenerDeregistered sibling) to
know whether there is at least an AT on the other side of the
accessibility bus.
This requires adding infrastructure to generate per-test data, so that
the random clip rect can be computed and reused for both test and
reference generation.
So add this infrastructure.
... and port the colorflip test.
This is so we can factor out generic parts of the code. This allows
making changes easier to those parts, like if we want to introduce
rules for what colorstates and memory depths to do diffs in.
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.
When comparing textures, always pick the colorstate from the reference
texture. This allows us to define what color state we expect.
For now, there's no check that the color states are equal, because they
don't really have to be as long as the pixels are.
Always pick the color state from texture1 and download the data and
generate the diff in that color state.
That now means the order of the 2 arguments matters.
I first tried porting everything to float, but it turns out that that
makes a compare-render run (with all 1520 tests succeeding) 9s slower
so I decided to keep the existing U8 code.
A side benefit is that saving the diff to PNG will continue creating
U8 PNGs.
We use the renderer to create the reference for the rotate test by
applying the same rotate transform to the reference image instead of the
tested node.
This is somewhat suboptimal because they run very similar codepaths, but
this method works with high bit depth content and different colorstates
This concludes the port away from gdk-pixbuf and means that all rendered
content and reference images can now use high bit depth and colorstates.
We use the renderer to create the reference for the colorflip test by
applying the same colorflip matrix to the reference image instead of the
tested node.
This is somewhat suboptimal because they run very similar codepaths, but
this method works with high bit depth content and different colorstates
We use the renderer to create the reference for the clip test by
applying the same clip node to the reference image instead of the
tested node.
This is somewhat suboptimal because they run very similar codepaths, but
this method works with high bit depth content and different colorstates
We use the renderer to create the reference for the flip test by
applying the same transform node to the reference image instead of the
tested node.
This is somewhat suboptimal because they run very similar codepaths, but
this method works with high bit depth content and different colorstates
and the gdk-pixbuf method does not.
We use the renderer to create the reference for the repeat test by
applying the same repeat node to the reference image instead of the
tested node.
This is somewhat suboptimal because they run very similar codepaths, but
this method works with high bit depth content and different colorstates
and the gdk-pixbuf method does not.
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
Up-until now, when a group of check boxes was created, they were
still presented as checkboxes, even they semantically were radio buttons.
Note that this approach will not always work, because we're not recreating the
AT context, but it works for the usual pattern where the group is set during
object construction
The default implementation of unselect_all calls
set_selection, which SingleSelection does not have
an implementation for (it's unclear what it would
do with multiple selections). Add a straightforward
implementation for unselect_all.
Using fine-tune on a GtkScale is maybe a little known feature, but it's
also quite wonky. It causes marks, values, and sliders to jump around
when activated. This is because it's implemented with less padding
around the scale and an increased minimum size.
For example a value drawn left or right of a horizontal scale, as then
the height of the scale is the value height plus padding. So fine-tuning
compresses the scale vertically.
We can fix this by adding negative margin on the trough instead, without
any changes to the padding or minimum size of the scale.
Also, because the trough now grows 3px in all directions, the slider has
to do that to, so that margin increases by 3px in all directions
compared to what it was, also for the cases with marks.
One last minor detail is that for vertical scales, fine-tuning causes
the height of the mark indicators to grow, whereas their width should
decrease. That's also fixed.
Commit d58b545f fixed a double counting of value size, but didn't check
whether that actually looked great. It doesn't.
Because the slider has negative margins, we need to add margin to the
value if it's on a side with no marks. If it is on a side with marks,
the scale will make it touch the marks. We therefore apply a mark's size
of margin to have the value be in the same place, with or without marks.
Commit d58b545f fixed a double counting of value size, but didn't check
whether that actually looked great. It doesn't.
Because the slider has negative margins, we need to add margin to the
value if it's on a side with no marks. If it is on a side with marks,
the scale will make it touch the marks. We therefore apply a mark's size
of margin to have the value be in the same place, with or without marks.
The texture ID is not deleted on dmabuf export; a copy is made, the
GskGpuImage retains ownership.
However when doing GL export, the texture *does* take ownership, so we
need the stealing semantics for that case.
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
The measured size of the range already includes borders that the scale
calculates. This includes the drawn value. So in the measurement of
scale, the size of the value shouldn't just be added to the size of the
scale, as then the size is effectively added twice.
To fix this, we first measure the minimum size of the range. Then, we
determine the minimum size of our scale. Only then do we set the minimum
size to maximum of those two values.
If both marks are set on top, and the value is drawn on top, the value
should be drawn outside the marks for a horizontal scale.
Currently, that order is incorrect, with the marks shifted up and the
value drawn between the slider and the marks.
This fixes that order.
We can get the position of the trough from the parent GtkRange class,
and can therefore align directly to that. There is no need to add
symmetry, which can always be added in CSS if needed.
Fixes#5171, #6639
This only makes the value allocation logic easier to understand, but
doesn't change anything, apart from not mixing integer and floating
operations anymore which can give a warning under some compiler
settings.
This reverts commit 2799632c02, reversing
changes made to 154035e76f.
That MR tried to fix#5171, but by doing a forced symmetry it introduced
another issue for users on Libadwaita, see #6639.
The logic can be much simplified, as the next commits show.
CI is hitting various limits after we started out with 32. In
particular, the default runners hit 90s test timeouts.
And the asan runner runs into max threads limits, so reduce that one to
4 tests max.
This is a test balloon tests that use /dev/udmabuf to produce
dmabufs that we can use in ci, even if we don't have a GPU.
Currently, the tests we can do are somewhat limited, since mesas
software renderers don't support dmabufs yet.
Instead of every test spawning their own dbus, make the tests share the
same server, just like they share their own compositor.
This should speed up things a bit and avoid weird interactions when
multiple dbus processes exist.
There are spurious failures happening in CI runs and I blame those on
too many processes running at the same time overloading either the
compositor we're running against, or causing OOM situations or just
genereally slowing things down and hitting timeout limits.
The choice of 32 is rather arbitrary. I just picked a number that felt
good.
We write a debug message and then handle things using fallback.
Fixes error messages when trying to import incompatible dmabufs.
(in my case: llvmpipe dmabufs into radv)
The value of `gtk-font-rendering` currently can't be specified
in "settings.ini", as the parser doesn't handle enums.
Allow reading values by enum nicknames.
Also cleanup obsolete references to rc files.
The non-shared context's surface must survive the lifetime of the
GL texture, and when the renderer gets unrealized the surface goes away,
but we cannot guarantee that all GL textures have been destroyed by
then.
So better use a context we know will survive becuase it isn't bound to a
surface.
This is the same fix for NGL as f3ac0535f8
was for GL.
This fixes a warning from the inspector's accessibility checker.
Users only control the menu model, not the menubar widget,
so this can only be done in gtk.
Instead of running one renderpass per clip region, run one renderpass for
the whole clip extents, and just set the scissor to the individual clip
rects.
This means that we need to use LOAD_OP_LOAD in cases where we don't
redraw the full extents, but nonetheless, the eprformance wins of
avoiding renderpasses are worth it, in particualr on tilers like the
Raspberry Pi or other mobile chips and the Apple M1/2.
We want to differentiate between CLEAR, DONT_CARE and LOAD in the
future, and the current boolean doesn't allow that.
Also implement support for the the different ops in the Vulkan
renderpass code.
This starts the renderpass at the given scissor rect.
It just splits out the gsk_gpu_render_pass_begin_op() call into a
simpler function, so it's harder to mess up.
Add gsk_gpu_node_processor_set_scissor() that allows resetting the
nodeprocessor's scissor and clip rectangle.
That in turn allows using the same nodeprocessor instance for all the
rects we draw for the clip region.
So they must not copy the fully_opaque flag from the child.
Adapted the testcase that accidentally caught it do now always catch it
by setting a proper background.
When we encounter many dead textures, we want to GC. Textures can take
up fds (potentially even more than 1) and when we are not collecting
them quickly enough, we may run out of fds.
So GC when more then 50 dead textures exist.
An example for this happening is recent Mesa with llvmpipe udmabuf
support, which takes 2 fds per texture and the test in
testsuite/gdk/memorytexture that creates 800 textures of ~1 pixel each,
which it diligently releases but doesn't GC.
Related: #6917
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 non-shared context's surface must survive the lifetime of the
GL texture, and when the renderer gets unrealized the surface goes away,
but we cannot guarantee that all GL textures have been destroyed by
then.
So better use a context we know will survive becuase it isn't bound to a
surface.
Since a4cc95b293, the emoji chooser
can fail to appear on smaller screens, depending on where its parent
widget is located. Stop requesting a fixed height to prevent this
issue.
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.
While the inspector is open, look for some shortcuts:
Super-r to toggle recording
Super-c to take a screenshot
A screenshot here means just a single-frame recording.
For convenience, we put the recorded frame onto the
clipboard too.
This should have gone into !7619 but gitlab managed to finish the CI run
just as I was pushing a new version to the MR with
merge_request.merge_when_pipeline_succeeds and apparently gitlab applied
that to the previous version or something.
So now that MR merged an incomplete version to main. And here's the fix
for that.
Use the clamp() API from the previous commit to:
1. Clamp values into range
2. Emit an error if values were out of range
Unlike CSS, which just clamps and doesn't emit an error, we do want to
emit one because we care about colors being correct in our node files.
This will make it easier for themes to style radio buttons
differently from check buttons, since out CSS does not have
:has().
The concrete desire here is to use a different outline for
the focus rectangle.
Update affected tests.
Fixes: #6936
The context->variables field is expected by the resolve code to be
the keyframe variables. That code takes the style variables from
context->style anyway, so no need to pass them as context->variables
too. And crucially, the lookup code treats the keyframes variables
differently to the style variables, since it doesn't expect the
hierarchical structure that comes from parent styles. This change
fixes infinite recursion in variable lookup with css like
:root {
--a: var(--b);
}
.foo {
--b: var(--a);
color: var(--a);
}
Test included.
Fixes: #6881
We don't currently support computing transforms across native
boundaries. This could be added by using gdk_popup_get_position_x/y.
For now, just fail in this case.
Related: #6355
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
On Windows, always use gtk_show_uri_win32 () instead of going through
GAppInfo. Hook up gtk_file_launcher_launch () to gtk_show_uri_win32 ()
as well, always extracting the file path (and not a URI) and propagating
the always-ask flag.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
This is a new internal utility to open/show/launch/execute URIs and
files on Windows, using Windows's native ShellExecuteEx () and
SHOpenWithDialog () APIs.
The advantages this has over using the win32 implementation of
g_app_info_launch_default_for_uri ():
* the implementation here is fairly simple;
* it doesn't involve trying to grok the registry for app / file type
registrations (at least not inside GLib/GTK side, the implementations
of ShellExecuteEx/SHOpenWithDialog presumably do that internally);
* it doesn't require convoluted formatting / escaping of invocation
command lines that GWin32AppInfo / gspawn-win32 has to do otherwise
(again, presumably the Windows libraries implement this internally);
* it's certain to end up opening the file/URI the same way other apps
in the system would;
* it can/will open the native system UI for picking an app in case there
are multiple options (or when so requested programmatically with the
always-ask flag), or if there is no app installed that can handle the
URI scheme / file type;
* it lets us pass the parent window handle, much like the portal APIs;
presumably Windows would use this for positioning the picking UI, or
placing the launched app's window;
* presumably, this will properly elevate privileges with a User Access
Control (UAC) prompt if the app being launched requires administrator
access; this presumably is impossible with the wspawn* APIs that
gspawn-win32 uses;
* this has a much better chance to work properly with the win32 app
isolation (AppContainer) technology.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
Make sure the radii are strictly positive.
Also handle the case where start >= end.
We can't really underline that error, because we don't track the
locations of the start/end properties until we know that there's an
error.
So just underline the whole radial gradient declaration.
Test included
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().
For some node types, the child nodes play different roles. E.g.
for a mask node, one of the two children is the source, the other
the mask. Show this information in the inspector.
Show the color state, and create textures with the full color
information.
The GdkRGBA-based helper functions are no longer used with this
commit and have been dropped.
It is not perfect, since PangoRenderer, GtkTextAppearance and
GtkTextTag all carry colors as PangoColor or GdkRGBA. But at least,
we get glowing foreground colors.
When transforming back from a complex transform to a simpler transform,
the resulting clip might turn out to clip everything, because clips can
grow while transforming, but the scissor rect won't. So when this
process happens, we can end up with an empty clip by transforming:
1. Set a clip that also sets the scissor
2. transform in a way that grows the clip, say rotate(45)
3. modify the clip to shrink it
4. transform in a way that simplifies the transform, say another
rotate(45)
5. Figure out that this clip and the scissor rect do no longer overlap
Catch this case and avoid drawing anything.
Show the color state, and create textures with the full color
information.
With this commit, add_color_row and get_color_texture are no longer
used and have been dropped.
Add a new GskShadow2 struct that has a GdkColor instead of
a GdkRGBA, and a new constructor and getter to go along with
it.
With this commit, my_color_get_depth is no longer used and
has been dropped.
Now that GDK can figure it out from the rendernode, doing all this work
trying to figure it out is no longer necessary.
Plus, it was sometimes wrong and lead to obscure artifacts.
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.
This is poking into the surface directly, so not a good idea.
And I want to hide that struct in the priv member.
Technically, this code should look at the opaque region, but I am lazy
and the GL renderer is on its way out, so I think it's not worth doing.
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.
Make sure both GL renderers don't leave their contexts alive via the
current context, but ensure they dispose of them properly.
Fixes issues when the corresponding GL resources in the surfaces they
were attached to go away.
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.
If we apply a rounded clip, we might change the clip in a way that makes
it intersectable with the scissor again, if both had diverged before.
So try and intersect with the clip.
I just spent an hour trying to figure out why things don't work. And it
was an optional dependency hidden 3 layers deep in some meson file.
This really has to stop.
And because just like in GTK, GStreamer's dmabuf APIs are always
available (they will just fail on Windows etc), there's no need to have
any conditions.
The only difference is that the GStreamer media backend now requires
GStreamer 1.24.
In the case of no offloading, we want to pass through to the child
(which is likely a big texture doing occlusion).
In the case of punching a hole, we want to punch the hole and not draw
anything behind it, so we start an occlusion pass with transparency.
And in the final case with offloading active, we don't draw anything,
so we don't draw anything.
This should fix concerns about drawing the background behind the video
as mentioned for example in
https://github.com/Rafostar/clapper/issues/343#issuecomment-1445425004
Container nodes save their opaque region, so it's quick to access. Use
that to check if the largest opaque region even qualifies for culling -
and if not, just exit.
Speeds up walking node trees by a lot.
Now that we can specify the min size for an occlusion pass, we can
specify that we want the full clip rect to be occluded for occlusion to
trigger.
The benefit of this is that for partial redraws we almost
always get the background color to cover the redrawn rectangle, so
occlusion will kick in.
When trying to cull, try culling from the largest rectangle of the
remaining draw region first. That region has the biggest chance of
containing a large area to skip.
As a side effect, we can stop trying to cull once the largest rectangle
isn't big enough anymore to contain anything worth culling.
When querying clip bounds, also check the scissor rect, because
sometimes that one is tighter than the clip bounds, because the clip
bounds need to track some larger rounded corners.
Makes a few tests harder to break.
Instead of requiring an occlusion pass to cover the whole given scissor
rect, allow using a smaller rect to start the pass.
When starting such a pass, we adjust the scissor rect to the size of
that pass and do not grow it again until the pass is done.
The rectangle subtraction at the end will then take care of subtraction
that rectangle from the remaining pixels.
To not end up with lots of tiny occlusion passes, add a limit for how
small such a pass may be.
For now that limit is arbitrarily chosen at 100k pixels.
gsk_gpu_node_processor_rect_to_device() is a useful function to have,
even if it has to return FALSE sometimes when there is no simple 1:1
mapping - ie when the modelview contains a rotation.
Instead of just iterating over all the rectangles of the region,
always draw the first rectangle of the region and subtract it when done.
This sounds more complicated, but it will allow us to modify the
rectangle in future commits.
Also change the way rectangles are printed by including the bottom right
coordinate, too.
I'm still not sure what the best way is, but at least I no longer get
confused and it has the infos I want.
Maintain cursor position even if the text in the entry has been filtered.
This is achieved by maintaining the same position with respect to
the end of the text buffer as we suppose that the text after the cursor
hasn't changed. This is measured in characters not bytes.
Fixes#6782
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.
Add a function that tracks whether a render node's content is
in a wide gamut color state (in practice, that means non-sRGB).
This will be used in render_texture to determine the color
state to use when creating a texture.
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.
When creating images for use with different colorstates, ensure that
they have the depth of that colorstate. Otherwise we might lose accuracy
due to quantization.
Fixes mipmaps in rec2100 being rendered as RGBA8.
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.
This is a simple fix, I did not investigate if NULL is actually possible
here.
In function ‘bitset_container_empty’,
inlined from ‘bitset_container_const_nonzero_cardinality’ at ../gtk/roaring/roaring.h:1942:13,
inlined from ‘container_nonzero_cardinality’ at ../gtk/roaring/roaring.h:4055:20,
inlined from ‘roaring_bitmap_lazy_xor’ at ../gtk/roaring/roaring.c:9727:17:
../gtk/roaring/roaring.h:1928:13: error: potential null pointer dereference [-Werror=null-dereference]
1928 | if (bitset->cardinality == BITSET_UNKNOWN_CARDINALITY) {
| ~~~~~~^~~~~~~~~~~~~
Pass the ccs, opacity and GdkColors to the op to let it make
decisions about color conversion. Also, reorder the offset to
follow the same order as the color ops.
Update the callers.
This test checks a that a specific combination of mask with alpha
inside opacity works as expected. We were treating the mask color
as premultiplied here, although it isn't.
We can't use gsk_gpu_node_processor_color_states_self() for ops which
apply alt to colors that don't come from textures, since those are
always unpremultiplied.
This fixes the + and - in disabled spin buttons appearing completely
white.
Add a new function callback called GtkTetBufferCommitNotify to be notified
of changes to a GtkTextBuffer without being involved in a signal chain.
This is necessary for some situations because signal handlers may modify
the parameters as they proceed down to default handler. As such, the signal
is unsuitable for applications heavily utilizing plug-ins such as Builder
due to non-deterministic signal connection ordering.
This technique has been used in Builder for the better part of a decade
and now would also vastly help in situations like libspelling where you
also want to know about changes to the buffer right before they are
committed to the b-tree.
Fixes: #6133
This creates a new color node that is meant to be identical to
an existing one, so we need to use gsk_color_node_new2 to preserve
the color state information.
Test included.
Allow defining cicp color states with an @-rule:
@cicp "jpeg" {
primaries: 1;
transfer: 13;
matrix: 6;
range: full;
}
And allow using them in color() like this:
color("jpeg" 50% 0.5 1 / 75%)
Note that custom color states use a string, unlike default color
states which use an ident.
Test included.
And allow using color states for colors with a syntax similar
to modern css color syntax.
color(srgb 50% 0.5 1 / 75%)
Both floating point numbers and percentages can be used.
Currently, this is only supported for color nodes.
Test included.
Use the color state returned by this function instead of assuming
the color of a color node is always sRGB.
Node colors are converted to the css on the cpu. That is necessary
since we don't know if they are in one of the default color states,
and our shaders can't deal with non-default color states.
Make color-related ops take the ccs and a GdkColor, and make
decisions about color conversion on the cpu vs the gpu.
This makes the node processor code simpler, and lets use convert
the color directly into the op instance without extra copying.
We also pass opacity to the op, so it can be applied when we
write the color into the instance.
Lastly, rorder the offset to come right after the opacity argument.
Treat the color and rounded color ops the same way.
Update all callers.
With this, the prepare_color apis in gskgpunodeprocessor.c are
no longer used and have been dropped.
This api lets one obtain a color state and color values from
a GtkCssColor. We don't want to force everything though sRGB,
but we can't quite avoid conversion here, since we don't have
a 100% match between the css color spaces and color states.
css color cleanup
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.
This is an old test that isn't very relevant anymore, and it has
some linking problems because it includes private headers that
have inlined functions.
This is a leftover from GTK3 when iconhelper sizes depended on the
texture size.
Now we only need to queue a redraw with the new icon.
Fixes warnings about resizes during allocate caused by scale change
notification during allocation of GtkWindow.
We want to reuse gsk_gpu_color_to_float() for use with GdkColor and this
function will be replaced. But until that's fully done, we need 2
different names.
So rename this one to something else
This is a GTK3 leftover where the icons were manually drawn and sized.
Now that they're managed by actual widgets that enforce a correct size
that is independent of scale factor, this is no longer necessary.
Fixes warnings about resizes during allocate caused by scale change
notification during allocation of GtkWindow.
Connect to "changed" signal of the entry displayed with combobox
for some options (e.g. watermark text or passcode). This ensures
that the strings are propagated to the printer backend.
Fixes#6782
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.
It turns out the "step" variable could up as 0 when p.y ~= 3.0 ||
p.y ~= r.y - 3.0
That was not enough to trigger it though because if "start" and "end"
were the same value, the "y <= end" check in the loop would immediately
terminate it.
However, if start + epsilon == end so that end != start but (end - start)
/ 7 == 0, then step would end up as 0 and the loop would never
terminate.
And if that happened, it would bring down GPUs.
So recode this whole machinery to make it impossible to infloop.
Fixes#6896
The fix in commit 5e7f227d broke shadows while trying to make them
faster.
So use a better way to make them faster.
With the normalized blur radius, we can now conclude that all the values
too far from p.y will cause the gauss() call to return close to 0, so we
can skip any y value that is too far from p.y.
And that allows us to put an upper limit on the loop iterations.
Tests included
Fixes#6888
Instead of doing complicated math, normalize the values to a sigma
of 1.0, and then use that.
This should also be beneficial for shader performance, because 1.0 is a
constant and constant-elimination can kick in on the inlined functions.
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.
Previously GTK required a C99 compiler, but as discussed on
GNOME/gtk!7510 there's at least one anonymous union in public API
(in `GskPathPoint`), and that's a C11 feature.
Signed-off-by: Simon McVittie <smcv@debian.org>
When we allocate a graphene_point_t on the stack, there's no guarantee
that it will be aligned at an 8-byte boundary, which is an assumption
made by gsk_pathop_encode() (which wants to use the lowest 3 bits to
encode the operation). In the places where it matters, force the
points on the stack and embedded in structs to be nicely aligned.
By using a distinct type for this (a union with a suitable size and
alignment), we ensure that the compiler will warn or error whenever we
can't prove that a particular point is, in fact, suitably aligned.
We can go from a `GskAlignedPoint *` to a `graphene_point_t *`
(which is always valid, because the `GskAlignedPoint` is aligned)
via &aligned_points[0].pt, but we cannot go back the other way
(which is not always valid, because the `graphene_point_t` is not
necessarily aligned nicely) without a cast.
In practice, it seems that a graphene_point_t on x86_64 *is* usually
placed at an 8-byte boundary, but this is not the case on 32-bit
architectures or on s390x.
In many cases we can avoid needing an explicit reference to the more
complicated type by making use of a transparent union. There's already
at least one transparent union in GSK's public API, so it's presumably
portable enough to match GTK's requirements.
Increasing the alignment of GskAlignedPoint also requires adjusting how
a GskStandardContour is allocated and initialized. This data structure
allocates extra memory to hold an array of GskAlignedPoint outside the
bounds of the struct itself, and that array now needs to be aligned
suitably. Previously the array started with at next byte after the
flexible array of gskpathop, but the alignment of a gskpathop is only
4 bytes on 32-bit architectures, so depending on the number of gskpathop
in the trailing flexible array, that pointer might be an unsuitable
location to allocate a GskAlignedPoint.
Resolves: https://gitlab.gnome.org/GNOME/gtk/-/issues/6395
Signed-off-by: Simon McVittie <smcv@debian.org>
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>
Similar to the previous commit, to avoid undefined behaviour we need
to avoid evaluating out-of-bounds shifts, even if their result is going
to ignored by being multiplied by 0 later.
Detected by running a subset of the test suite with
-Dsanitize=address,undefined on x86_64.
Signed-off-by: Simon McVittie <smcv@debian.org>
If, for example, e == 0, it is undefined behaviour to compute an
expression involving an out-of-range shift by (125 - e), even if the
result is in fact irrelevant because it's going to be multiplied by 0.
This was already fixed for the memorytexture test in
commit 5d1b839 "testsuite: Fix another ubsan warning", so use the
implementation from that test everywhere. It's in the header as an
inline function to keep the linking of the relevant tests simple:
its only caller in production code is fp16.c, so there will be no
duplication outside the test suite.
Detected by running a subset of the test suite with
-Dsanitize=address,undefined on x86_64.
Signed-off-by: Simon McVittie <smcv@debian.org>
Left-shifting a signed 32-bit integer by 31 bits (such that the value
overflows into the sign bit) is undefined behaviour. Use an unsigned
integer instead.
Detected by running a subset of the test suite with
-Dsanitize=address,undefined on x86_64.
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>
Shifting a 32-bit type by 32 bits is formally undefined behaviour,
even if it happens in code that is unreachable at runtime. Use a
compile-time check against GLib's GLIB_SIZEOF_SIZE_T, instead of hoping
a runtime check will be optimized away.
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>
Middle clicking without a selection left a paste point override behind.
This meant actual pastes were going to the location of the middle click,
instead of the cursor
Closes#5530
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.
The signal is declared in GtkTestATContext with 0 parameters, but these
handlers were written as if the signal had one `guint` parameter.
On some architectures this accidentally works as intended, but on
others (reproduced on i386 and riscv64) the test tries to use arbitrary
stack contents as the `TestData *` and crashes when it tries to
dereference the resulting non-pointer.
Resolves: https://gitlab.gnome.org/GNOME/gtk/-/issues/6490
Signed-off-by: Simon McVittie <smcv@debian.org>
When the cicp values coming out of GStreamer are unspecified, replace
them with the default cicp values for YUV video: 1/13/6.
We still may end up with unspecified values inside the params, because
GStreamer returns unspecified for primaries/tfs/matrices that aren't
supported by cicp.
See also https://github.com/AOMediaCodec/libavif/wiki/CICP#unspecified
fora similar discussion.
This regression was introduced in aeac2b54.
We need percentage values to stay non-computed, since we otherwise
fail to compute relative font sizes properly. But we want percentages
not to stick around in relative colors, so tweak things to be more
aggressive with simplication when creating relative color values.
Update affected tests.
Fixes: #6868
With the changes in !7473 we now use sampler2D arguments in functions.
However, when there's a function we call with a samplerExternalOES -
which means we need to overload it with that shader variant.
The later CICP changes made the cicp params we were setting unustable.
Set ones that work in the current state of git main. They are still
imperfect, but they reflect the current code.
We were using slightly different numbers here, which isn't good.
The matrices in gdkcolordefs.h are tested in the colorstate-internal
tests, so they are at least properly inverse, and the products match.
It would be better to generate the glsl definitions, somehow.
Add some more texture conversion roundtrips. They are currently
ifdefed out, since they need cicp api.
Also add another test binary for internal tests.
When we the image color state is not a default one, use the cicp
convert op to convert it to the ccs. And when the target color
state is a non-default one, use the shader in the reverse direction.
This shader receives cicp parameters via uniforms, and converts
the texture data from or to the output colorstate. It computes
the matrix in the vertex shader, and then picks the eotf/oetf
according to the cicp parameters in the fragment shader.
This adds machinery to create colorstate objects from cicp
tuples, as well as a function to return a cicp tuple for a
colorstate.
Still missing: a conversion shader for non-default colorstates.
Our conversion machinery supports converting from any color
state to any default color state or back. Direct conversion
between two non-default color states isn't guaranteed. For
converting *to* a cicp color state, we need this function.
We want to get PFD_SWAP flags as that's required to enable incremental
rendering. However, as documented on MSDN, ChoosePixelFormat ignores
PFD_SWAP flags.
We may get PFD_SWAP flags or not depending on the way the OpenGL driver
orders its pixel formats. While PFD_SWAP flags are very important for
GUI toolkits, they are best avoided by games, as most games render the
scene in its entirety on each frame. Drivers optimized for games tend
to order pixel formats with no PFD_SWAP flags first.
Se we implement our own method to select the best pixel format. We check
for usable pixel formats and assign penalties for each one, until we find
a format with 0 penalty or the sequence ends. Then the best pixel format
is selected.
Getting a defined swap method is necessary to enable incremental
rendering. We cannot just add a swap method attribute since
exchange is generally preferred, but is not always available.
Here we try to infer what the driver prefers, then ask for
exchange or copy, in sequence.
Vulkan objects are integers on 32bit and it's failing when it's set to
just NULL.
```
../gdk/gdkvulkancontext.c:677:24: error: assignment to ‘VkSemaphore’ {aka ‘long long unsigned int’} from ‘void *’ makes integer from pointer without a cast [-Wint-conversion]
677 | priv->draw_semaphore = NULL;
```
We were passing the wrong rect to the clip mode computation, resulting
in a rounded rect every time, even though it should pretty much always
be unclipped.
The visual results are unaffected, because the clip sent to the shader
was still correct.
Instead of allocating one large descriptor pool and hoping we never run
out of descriptors, allocate small ones dynamically, so we know we never
run out.
Test incldued, though the test doesn't fail in CI, because llvmpipe
doesn't care about pool size limits. It does fail on my AMD though.
A fun side note about that test is that the GL renderer handles it best
in normal operationbecause it caches offscreens per node and we draw the
same node repeatedly.
But, the replay test expands them to duplicated unique nodes, and then
the GL renderer runs out of command queue length, so I had to disable
the test on it.
There is now a GskGpuYcbcr struct that maintains all the Vulkan
machinery related to YCbCrConversions.
It's a GskGpuCached, so it will make itself go away when it is no longer
used, ie a video stopped playing.
Now that we don't use the fancy features anymore, we don't need to
enable them.
And that also means we don't need an env var to disable it for testing.
Now that we don't do fancy texture stuff anymore, we don't need fancy
shaders either, so we can just compile against Vulkan 1.0 again.
And that means we need no fallback shaders for Vulkan 1.0 anymore.
Instead of trying to cram all descriptors into one large array and only
binding it at the start, we now keep 1 descriptor set per image+sampler
combo and just rebind it every time we switch textures.
This is the very dumb solution that essentially maps to what GL does,
but the performance impact is negligible compared to the complicated
dance we were attempting before.
Rewrite all shaders to use 2 predefined samplers called GSK_TEXTURE0 and
GSK_TEXTURE1 instead of wrapper functions.
On GL and Vulkan compat mode, these map directly to samplers.
On Vulkan proper, they map to 2 indices into the texture array, like
before.
From now on, the old nvidia GPUs - ie the 3xx drivers - should start
working again.
Fixes: #6564Fixes: #6574Fixes: #6654
This allows GskGpuFrame implementations to store data per vertex
attribute.
This is just the plumbing, no actual implementation is done in this
commit.
This guarantees that the images get ID 0 and 1 (on GL), which is going
to be quite important for the next steps.
Just for funsies, here's fps numbers on my desktop for this change:
NGL 1500 => 1400
Vulkan 2650 => 2250
This by itself is just more work refcounting all those images, but
there's actually a goal here, that will become visible in future
commits.
But this is split out for correctness and benchmarking purposes (the
overhead from refcounting seems to be negligible on my computer).
Just define GSK_N_TEXTURES in every glsl file, extract that #define in
the python parser and emit a static const uint variable
"{shader_name}_n_textures" in the generated header.
It's a struct collecting all relevant info for a texture passed to a
shader.
The ultimate goal is to get rid of the descriptors and let ops
manage them on thir own.
If GskGpuCache has an idea of what time it is, cached items can use that
time to update their last-use time instead of having to carry it around
throught function calls everywhere.
Port an optimization of the GL renderer where it fast-paths crossfades
with progress <= 0 and >=1 - which should really never happen because
nobody should emit them in the first place, but oh well.
YUV dmabufs are not sRGB.
So instead of making the dmabuf builder have sRGB as the default
colorstate, add a NULL default option that makes the builder choose
the colorstate based on fourcc when build() is called.
If that happens, we pick sRGB usually, but for YUV we pick narrow range
BT601, like we did in versions before colorstates.
We no longer hardcode the few different classes we have, but generically
walk over all classes.
As a side effect we now get new classes added to stats automatically.
The content itself did not change.
Commit 1580490670 included a reordering of
acquiring the frame before making the context current.
Sometimes (like at startup) new frames need to be created.
Setting up a new frame assumed the GL context was current.
Change it so that we delay the one GL setup we do in frames until later.
Building GTK with GCC 8 results in the following warning:
gtk/gtkurilauncher.c: In function ‘gtk_uri_launcher_launch’:
gtk/gtkurilauncher.c:315:3: warning: this ‘else’ clause does not guard... [-Wmisleading-indentation]
else
^~~~
gtk/gtkurilauncher.c:317:1: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘else’
G_GNUC_BEGIN_IGNORE_DEPRECATIONS
^~~
In the compiled code, gtk_show_uri_full () is invoked whether the portal
branch is taken or not, leading to use-after-free of the task.
It looks like GCC in versions older than 12 treats the _Pragma(s) that
G_GNUC_BEGIN_IGNORE_DEPRECATIONS expands to as C-level statements, and
therefore the pragma takes up the 'else' statement slot.
See https://godbolt.org/z/e5zqbaqxo for a simple reproducer.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
* We cannot map with offset, because offsets need to be page-size
aligned. And our code doesn't expect an offset anyway.
* The error return value from mmap() is MAP_FAILED aka -1, not NULL aka
0.
Vulkan requires us waiting on the image acquired from
vkAcquireNextImageKHR() before we start rendering to it, as that
function is allowed to return images that are still in use by the
compositor.
Because of that requirement, vkAcquireNextImageKHR() requires a
semaphore or fence to be passed that it can signal once it's done.
We now use a side channel to begin_frame() - calling
set_draw_semaphore() - to pass that semaphore so that the
vkAcquireNextImageKHR() call inside begin_frame() can use it, and then
we can wait on it later when we submit.
And yes, this is insanely convoluted, the Vulkan developers should
totally have thought about GTK's internal designs before coming up
with that idea.
These are just factoring out gdk_draw_context_begin/end_frame() so I can
add one tiny thing there later.
And I did both even though I only need one, because it felt wrong to
just do one.
Make the function look like that:
1. handle special case
2. maybe GC
3. draw
4. queue next gc
5. cleanup
This seems like the sanest approach to avoid gc() collecting things
necessary for drawing in the future.
And I need to refactor stuff, so having it out of the way is a good
idea.
When loading or saving png files, encode the CICP flags of the color
state into the PNG.
When loading, decode the CICP flags if available and detect the
colorstate they use.
If we do not support the cicp tags, we do not load the image.
So far, we ignore the ICC profiles.
Includes regeneration of nodeparse test *reference* output to include
the new tags we write to PNGs.
The original tests do not include those tags, so we implicitly test that
we read untagged files correctly.
We only download the data when we actually need it for writing into the
PNG stream.
This allows modifying the download parameters (in particular color state
in the next commit) while writing out their settings, so the code for
selecting the right colorstate liives in only one place.
We have to be careful though, because the download now happens after the
setjmp(), so we need to make sure the error path handles both cases
without leaking: Where the download has happened and where it hasn't.
Same thing as dmabuf and GL texture builders. Preparation for adding
color state support to texture constructors.
As a bonus, we can now do update regions with memory textures.
... and plumb the color state through the downloading machinery, where
no matter what path it takes it ends up in
gdk_memory_convert_color_state() or gdk_memory_convert().
The 2nd of those has been expanded to optionally do colorstate
conversion when the 2 colorstates are different.
When a cache item is invalid, don't move it into the hash table.
Instead, just delete it.
Something like this could happen:
1. A texture is cached
In the case of #6867 this would be a webpage in epiphany.
2. The texture cache item is garbage-collected
For example, epiphany might switch to a new tab, and the previous page's
texture will remain. After 15s or so, we collect our item for that
texture.
3. The texture is cached again, but in the target colorspace
We now decide we need the texture again, but not in any colorspace, we
need it in the target colorspace. This might be because we run an
effect on it (like a crossfade) or because we want mipmaps (like in the
overview map, where its zoomed out).
4. The old invalid item is transitioned into the hash table
We now have an invalid item in the hash table. This is extra bad,
because it had only one reference (from the texture), but we treat it
like it has 2 (from us in the hash table and from the texture).
So depending on if the texture is freed before we reuse it, we get
different results: If it was free, we get invalid memory accesses, if it
was not freed, we treat it like a valid cache item and think the image
inside is still valid.
Fixes#6867
This happens when buffer creation fails in `get_dmabuf_wl_buffer()` and
we manually call `listener->release (data, NULL)`.
Fixes: 2478dd8322 ("subsurface: Split a function")
Private function `gtk_print_setup_get_printer` unconditionally calls
`gtk_printer_find()`, which does not exist on Win32.
But `gtk_print_setup_get_printer()` is never called either, so usually
that whole code gets optimized out.
Some compilation environment however do not cleanup unused functions,
leading to linker error as `gtk_printer_find()` is not found.
This patch should solve the link issue.
gsk_gpu_device_gc() may release the last ref on the GskGpuDevice,
leading to memory corruption when setting priv->cache_gc_source = 0.
Includes a bit of refactoring, so the ref/unref wraps nicely around the
actual code.
Fixes crashes seen after using the inspector and closing the window,
thereby closing all windows of a display and releasing all references to
the device.
Fixes#6861
This is a still experimental protocol (thus the xx prefix).
We are using it go obtain information about the compositors
preferred color state, and pass that on to our rendering machinery.
The currently supported color states are srgb, srgb-linear, rec2100-pq
and rec2100-linear. We don't have any support for ICC profiles.
Unlike other protocols, keep the support code for this protocol
fairly isolated behind wrapper objects, since the protocol is
still subject to change.
begin_frame is the place where we make decisions about the format,
depth and colorstate for our rendering. Make these calls take the
surface color state into account.
In particular, if the surface colorstate is suitable for GL_SRGB,
and we don't need high depth, set things up for that.
Change the glsl convert_color function to proceed in stages:
- first unpremultiply
- then linearize
- then transform linearly
- then delinearize
- then premultiply
All the steps are only taken if needed.
We only want to measure visible columns so that they may consume the
maximum width available to the widget. This fixes a situation where hidden
columns would cause less-than the whole width to be allocated. Additionally
that fixes warnings where some widgets expect more horizontal space than
they would ultimately be allocated.
The modern incantation to get validation layers enabled is via
VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation
Vulkan has a bunch of environment variables to toggle stuff, let's use
those instead of doing our own.
We need to make sure our clear values are in the right colorstate, not
in sRGB.
The occluision culling managed to sneak through the big transition for
that.
This is actually the node Loupe is using, so having tiling work with it
is important.
Because of the previous commit, different filters are supported fine.
Fixes: #6324
This allows mipmapping if downscaled a lot, like we do for non-tiled
images.
A side effect is that due to the simpler caching for tiles, we can only
cache the mipmapped images in one colorstate. But we need to pick a
potentially non-default one, because we want to mipmap in a linear
colorstate.
So this is somewhat suboptimal. Patches with improvements accepted.
Use the new cache feature to split oversized textures into tiles the
size given by the new device API.
Then number those tiles from left to right and top to bottom and use
that number as the tile id.
When we draw large images, we absolutely do not want to keep memory that
we do not need. So do a GC run after every tile. That otentially slows
down things, but it also improves the chances of not running out of
memory.
Here's the node for the image I managed to create after I applied this
patch:
repeat {
bounds: 0 0 50000 50000;
child: text {
font: "Noto Color Emoji 10000px";
glyphs: 661 0 0 0 color;
offset: 0 10000;
hint-style: none;
}
}
Functions should behave as I expect, and I just spent an hour debugging
a refcount issue because I assumed our image creation functions return
refrences. Which is a very sane assumption.
The settings portal is reporting enums as string values, so
we need to translate this setting back to what we need.
Fixes
(gtk4-demo:18902): GLib-CRITICAL **: 19:06:14.783: g_variant_get_int32: assertion 'g_variant_is_of_type (value, G_VARIANT_TYPE_INT32)' failed
that could be seen in recent nightly flatpaks.
The texture and texture-scale node code is creating image copies
for mipmaps and to adapt to the compositing colorstate.
Those texture should be cached.
We want to cache textures in the compositing color state, not in their
original color state. However, the compositing color state may change
(think multimonitor setups).
So we additionally keep a cache per colorstate.
That means texture lookup is now a 3-step process:
1. Look up in the compositing colorstate's cache
2. Look up in the general cache
3. Upload
GL_SRGB is doing postmultiplied alpha, so if the texture is
premultiplied, we can't use this optimization.
The optimization still works for unpremultiplied and opaque images,
because those don't do that step.
No colorstate conversions allowed here, though technically we could use
the alternate color state for the source most of the time, as the mask's
colorstate is only relevant for luminance.
This is a function that's meant to be used whenever both color states
of the shader are equal. In that case no colorspace conversion code
needs to be created and shaders can be shared.
The GL renderer is using FLOAT32 instead of GL_SRGB, which is screwing
up the node-editor by making it turn on high bit depth unconditionally.
So until someone fixes the GL renderer properly, do this quickfix.
That way, we can use it in one other place where we want to use mipmaps.
I don't really like it because it adds yet another argument,
but then the one new caller was selecting suboptimal shaders, and that's
worse.
The colormatrix shade does a whole matrix multiplication, which is
absolutely not necessary.
The convert shader has builtin opacity handling and when the colorstates
match will do no conversion.
Previously, we were always downloading into CAIRO_FORMAT_ARGB32.
Now we check the texture depth and pick a suitable format.
This improves rendering for high depth content, but it's slower.
That's why we're not yet making sure the depth is suitable for the
colorspace conversion. That would force all SRGB textures into float
surfaces as we don't consider conversions suitable for U8 in our generic
code.
The alternative color state is used as the interpolation color state.
Colors are transformed into that space on the CPU.
For now we set the interpolation color state to SRGB, because ultimately
we want to let callers specify it, so having something that's easy to
map to that behavior is desirable.
Otherwise we might have chosen to interpolate in the compositing
colorstate.
It also means that we need to premultiply colors on the CPU now because
of the limitations of the shader colorstates APIs.
This makes use of the GskGpuColorStates by setting the ccs as output
colorstate and the color's colorstate as alternative color state.
The shader adaption is very straightforward because of that.
This is the first op to obey the compositing color state. This means
from now on until all ops obey the ccs rendering is broken when ccs is
not set to linear.
I'll keep individual ops in seperate commits for easier review, because
they all need different adaptations.
Render to an offscreen and add a final conversion if the target
colorstate is not a rendering colorstate.
This now allows the GPU renderer to render to any colorstate.
Makes the verbose output (a lot) more verbose, but it makes the
colorstates used in the shaders very visible.
And it will be relevant once people start using different colorstates
everywhere (like oklab for gradients/colors and so on).
This adds the following functions:
output_color_from_alt()
alt_color_from_output()
Converts between the two colors
output_color_alpha()
alt_color_alpha()
Multiplies a color with an alpha value
This adds a GdkColorStates that encodes 2 of the default GdkColorStates
and wether their values are premultiplied or not.
Neither do the shaders do anything with this information yet, nor do the
shaders do anything with it yet, this is just the plumbing.
If desired, try creating GL_SRGB images. Pass a try_srgb boolean down to
the image creation functions and have them attempt to create images like
that.
When it is not possible to create srgb images in the given format, just
fall back to regular images. The calling code is meant to check the
GSK_GPU_IMAGE_SRGB flags to determine the actual format of the resulting
image.
Make the node processor and the pattern writer track the current
compositing color state. Color state nodes change it. We pass
the surface color state down via the frame apis.
The name of the variable is "ccs" for "compositing color space". It's an
unused variable name and it's common enough to deserve a short and sweet
name.
This shader converts between two color states, by using the
same functions that we use on the cpu. The conversion to perform
is passed as part of the variation.
As premultiplication is part of color states on the shader, we also
encode the premultiplication in the shader.
And because opacity is a useful optimization, we also allow setting
opacity.
For now, the only possible color states are srgb and srgb-linear.
This adds the following:
- ccs argument to GskRenderNode::draw
This is the compositing color state to use when drawing.
- make implementations use the CCS argument
FIXME: Some implementations are missing
- gsk_render_node_draw_with_color_state()
Draws a node with any color state, by switching to its compositing
color state, drawing in that color state and then converting to the
desired color state.
This does draw the result OVER the previous contents in the passed in
color state, so this function should be called with the target being
empty.
- gsk_render_node_draw_ccs()
This needs to be passed a css and then draws with that ccs.
The main use for this is chaining up in rendernode draw()
implementations.
- split out shared Cairo functions into gdkcairoprivate.h
gskrendernode.c and gskrendernodeimpl.c need the same functions.
Plus, there's various code in GDK that wants to use it, so put it in
gdk/ not in gsk/
gsk_render_node_draw() now calls gsk_render_node_draw_with_color_state()
with GDK_COLOR_STATE_SRGB.
Make begin_frame() set a rendering colorstate and depth, and provide it
to the renderers via gdk_draw_context_get_depth() and
gdk_draw_context_get_color_state().
This allows the draw contexts to define their own values, so that ie the
Cairo and GL renderer can choose different settings for rendering (in
particular, GL can choose GL_SRGB and do the srgb conversion; while
Cairo relies on the renderer).
That's basically the "undefined" value. We need that when drawing
nothing, which so far only happens with empty container nodes.
But empty container nodes can be children of other nodes, and that makes
things propagate. So instead of catching them, force the whole rest of
the code to deal with an undefined depth.
We also can't just set a random depth, because that will cause merging
to fail.
Make our visual selection code prefer fbconfigs that are
'srgb framebuffer capable', and mark the surface as 'is srgb'
in this case.
This arranges things so that GSK knows not to use an offscreen
for converting contents back to srgb in the end.
For GDK_MEMORY_U8_SRGB depth, try to create an SRGB surface.
This requires the EXT_KHR_gl_colorspace extension, which
isn't super-common in the wild (37%), so we fall back to regular U8 if
that fails.
But if we have the extension, create our egl surface with the
srgb colorspace, and report that fact in gdk_surface_gl_is_srgb().
We still only differentiate between high bit depth or not, but we now
choose at the end instead of the start, which makes it easier to adapt
to a different method of choosing.
This is an experiment for now, but it seems that encoding srgb inside
the depth makes sense, as we not just use depth to decide on the
GL fbconfigs/Vulkan formats to pick, depth also encodes how the [0...1]
color values are quantized when stored.
Let's see where this goes.
This commit just adds the flag, but I wanted to make it an individual
commit to explain the purpose:
The SRGB flag is meant to be used for images that have an SRGB format.
In Vulkan terms, that means VK_FORMAT_*_SRGB.
In GL, it means GL_SRGB or GL_SRGB_ALPHA.
As these formats have been madatory since GL 3.0, we can (ab)use them
uncoditionally. Images in these formats are renderable, too, so it's
not just usable for uploading.
What these images allow is treating the data as sRGB while shaders
access them as linear, thereby getting sRGB<=>linear conversions for
free.
It is also possible to switch off the linearization of these images and
treat them as sRGB, which allows all sorts of shenanigans, though one
has to be careful if that turning off applies to the relevant GL/Vulkan
code in question.
Returns the linear color state that renderers should render in when
this is the target color state.
We disable this function unless linear compositing is enabled and just
return @self by default.
This function checks if the colorstate uses an sRGB transfer function
as final operation. In that case, it is suitable for use with GL_SRGB
(and the Vulkan equivalents).
We disable this function (by always returning NULL) unless linear
compositing is enabled, because this function is used to transition
textures and framebuffers to their linear counterparts.
This is mostly an empty shell for now. We only have static instances
for srgb and srgb-linear, which we will use as markers during our
node processing.
In the future, this object may grow more instances, as well as the
ability to create them from and save them to icc profiles or cicp
data. And a color conversion API.
This is a temporary solution to allow testing how well linear rendering
already works while refactoring code.
This will be removed once linear rendering is the default.
If the GL texture is exportable to a dmabuf, we can just use our dmabuf
importing code to get that texture into Vulkan.
There is no need to go via host memory in that case.
And if it doesn't work, we just fall back, like before.
We have code with proper error handling for dmabuf export, we can just
try to use it.
And if it doesn't work, we don't offload the texture like before.
But it does work - at least for me.
Instead of hardcoding which textures we presumably support, just try
creating a buffer and use the failure of that for the error message.
This makes the error message a bit less obvious, but it makes it
possible to refactor the get_buffer() code without having to deal with
the error path.
If we want to improve the debug message, we can start putting debug
messages into the get_buffer() function.
But I think this is good enough.
Unimplemented nodes are a failure now.
We make this a soft failure with a g_warning() so that during
development when adding new nodes, the renderer doesn't instantly crash,
but instead prnts a warning.
But we do consider unimplemented nodes a bug now.
Because of that, add_fallback_node() is now renamed to add_cairo_node().
Everyone should draw the error pink here, because that's what the
renderers not supporting it do, and it's also what the default shader
does.
So no matter if a renderer supports GL shaders or not, it should draw
the same pink.
When determining which way is up for the offloaded texture, we
must take all transforms into account - the ones outside the
subsurface node, and the ones inside.
By moving negative affines to be treated like dihedrals, because they
also need support of the modelview, we can free up the affine branch for
doing work without it.
Not a big win I guess, but it makes scaling more efficient.
This allows handling them without ever needing to offscreen for losing
the clip, because the clip can always be transformed.
Also, all the optimizations keep working, like occlusion culling,
clears, and so on.
The main benefit of this work is the ability for offloading to now
handle dihedral transforms of the video buffer.
The other big advantage is that we can now start our rendering with a
dihedral transform from the compositor.
This category does a finer-grained categorization than
GskTransformCategory, but it is deliberatedly made to allow
easy backwards compatibility.
The reason for the categories is that they fit our renderers more
fine.
In particular, it allows implementing wl_output_transform support more
efficiently, thereby allowing rendering buffers the right way for
rotated phone screens or monitors.
The rectangles need to touch/overlap in both directions, otherwise
there's no coverage that covers both rectangles.
Test included.
Fixes rendering glitches in various apps when redrawing.
Fixes: #6849
... instead of init_draw(); add_node(); finish_node();
We hook into the infrastructure one step earlier and close to where the
default renderer_render() and renderer_render_texture() arrive in the
nodeprocessor.
Why is this relevant?
Because process() does occlusion culling.
TL;DR: offscreens do culling now
We import them as general, so they should be exported like that.
This was a longstanding issue that I never got around to fixing and I'm
touching this code anyway atm.
See commit 3aa6c27c26 for more details.
NULL disables clearing. We only implement this for GL as in Vulkan we'd
need to create different renderpasses with different attachment
descriptions and that would require more plumbing.
We need to check that the clip is inside the opaque region, not that the
opaque region is inside the clip.
Test included, using the only not that hits the fallback path with an
opaque region smaller than its bounds.
Sometimes container nodes contain lots of overlapping opaque items. In
that case we can use the container node itself as the first node even
though none of the children cover the whole paint area.
The use case for this is a grid of cells like in a terminal where all
the cells are opaque and we want to avoid drawing the background behind
them.
If the color was specified using the legacy rgb(), we must accept
values in the range [0, 255]. But when serializing it as
color(srgb...), we must scale those values to [0, 1].
Update the one affected test.
When the color property is inherited, don't resolve the inherited
value to find the used value, just inherit the used value of the
parent style.
This is what browsers do, even though the spec says something else.
Update the currentcolor4 style test to reflect these changes.
Fixes: #6833
We were not handling the is_computed and contains_current_color
flags correctly when creating new color values. Set these flags
propertly. is_computed means: calling compute() won't change the
value. contains_current_color means what it says.
We are seeing posix_fallocate fail with ENOENT occasionally.
This shouldn't happen according to the docs, but it does. Fall back
to ftruncate if it does. It gives us less guarantees, but it makes
the ci not fail so much.
Due to the way the intermediate offscreen gets drawn, we might end up
with seams at the edges.
And I don't think it's worth spending more time on than saying "not
opaque".
Fixes the compare-render testsuite
New testcase included.
We want to operate with opacities, so it makes sense to have this radily
available.
And we're doing a walk over all children on creation anyway, so why not
just capture the rect there.
We want to be able to express opaque grids. This means that the app
provides either a row of columns of opaque nodes or a column of rows,
and then the containers will magically figure it out.
The main use case for this is terminals, which are uilt using cells. And
when there's a transparent background configured but the contents are
opaque, it'd be nice if we could figure that out.
Also remove the 80% requirement. It is rather arbitrary and while it
helps for some cases, the aforementioned grid would suffer.
Clip nodes often appear in the widget tree.
And the implementation can be trivial because of the sanity checks
already performed before calling the vfunc.
This is required because transform nodes appear everywhere.
We just exit for all transforms that can't transform the clip rect
losslessly. Both because they are rare and because we'd make the
coverage possibilities much lower.
Containers can walk the list of children back to front, trying to find
the topmost node that fully covers the viewport.
And then they can skip drawing all the nodes before that one.
Asks a node to add itself if it is fully covering the clip rectangle.
In that case, it is the first node that needs to be added.
If the node is not fully covering the clip, it should not draw itself,
because there might be stuff needing to be drawn below.
If a node adds itself, it should call gsk_gpu_render_pass_begin_op().
We find the first child that covers >80% of the container and return
that.
This is a nice speedup for the common case of a GtkWindow being covered
by a large opaque background.
It will fall apart for fancy themes that play with transparency or for
small windows because the shadow region gets too large.
But then we just scan the whole node tree.
We could think about adapting the 80% number, because that wasn't chosen
with any real scientific data behind it.
This takes both the vertical and horizontal rectangle that isn't
covering the rounded corners and intersects both with the child's opaque
rect.
And then it returns the larger of the two.
This means the small slices of a window near the left/right (or
top/bottom) will never be covered, but if we wanted that, we'd need to
use something else than a rectangle - either a region or actually a
rounded rect.
But that is a lot more expensive to implement.
Tests are node files dumped into testsuite/gsk/opaque
They are named "name-X-Y-W-H.node" with X Y W H being the expected
opaque rectangle or "name.node" if there is no opacity.
A simple example is included here.
We can in fact meet complex transforms here. Asserting that they
are simple doesn't make it so. Instead, simply bail out if a
transform is too complex; in this case we can't offload anyway,
so no need to walk the tree further.
Test included.
Fixes: #6824
We wanted premultiplied images in all cases anyway, and moving that
requirement means we can also move the caching code for re-caching
textures into the texture specific code.
This uses offscreens for every call to get_node_as_image().
This is useful both for benchmarking benefits of those implementations
as well as checking that the node-specific paths produce identical
results.
gsk_gpu_node_processor_ensure_image() was a weird amalgamation of stuff
withe weird required and disallowed flags.
Refactor it to make the two operations we actually do there more
explicit: Removing straight alpha and generating mipmaps.
This untangling is also desirable in the future when we also want to
handle colorstates here.
Always return premultiplied images.
2 fallback cases for clip and transform nodes did not require that. If
those cases turn out to be important, they can call
gsk_gpu_get_node_as_image() directly as that's the more flexible option.
Pass through to the child instead of offscreening.
I mainly implemented it for the assertion, because this might be a
sneaky way to introduce bugs without exhaustive checking that we don't
offload stuff that is offscreened.
No actual bugs that I'm aware of, so no tests.
Strictly defensive coding.
When getting a texture as image, we were always returning the texture
unconditionally.
However, we want to mipmap textures when the scale factor is too large,
and this code path did not do that.
The same codepath on the GL renderer doesn't do that either, so the test
is disabled for it.
The switch statement was ugly.
Plus, the code should be close to the add_node() vfunc implementation,
so they can be modified together.
See future commits for an example where this matters.
Make the whole window area draggable, like usually the titlebar.
This is especially useful with --undecorated.
In that case we need to make the window non-resizable though, becuase
otherwise it can be accidentally maximized and whatnot.
It didn't bring any noticable benefits and it isn't compatible with the
way we intend to do colorstate support.
And nobody seems to want to spend time on it, so let's get rid of it.
We can bring it back later if someone wants to work on it.
* The variables are const. Keep them const when casting
* Print float16 values
* Print integer values as hex. This is better for detecting
byteswapping, off by one, and such. Besides, we tend to use values
that have the same 2 hex digits, so detecting corruption is also easy.
The new renderers don't support them due to the required complexity of
integrating them with Vulkan and the assumptions those nodes make about
the renderer (the GL renderer exports its internal APIs into the
GLShader).
There haven't been any complaints that I'm aware of since 4.14 was
released where the default renderer does not support the nodes, so usage
in public seems to be close to nonexistant.
The 2 uses I know of were workarounds about missing features in GTK that
have stopped since GTK now supports them:
1. GStreamer used in to do premultiplication when the old GL renderer
did not do so in hardware but on the CPU.
2. Adwaita used it for masking before the mask node wa added in 4.10.
I was watching the log in my terminal and nothing happened.
And I wasn't sure if that was because nothing was printed or because the
same thing was printed every few seconds.
Fix that by printing a timestamp, so that in a few seconds something
else will be printed.
Previously we tracked the dead pixels, but that meant we didn't know the
alive pixels (because there's also unused pixels never accounted for).
And we would free the current atlas randomly due to that.
Now we track if any pixels are alive, and if so, we never gc the current
atlas.
After 60s, we gc the atlas, too. This ensures that after that time, we
free all cache resources, so if an application gets moved to the
background, it will no longer use GPU resources. (Well, at least the
cache won't.)
Only if a non-stale item is in the cache do we consider the cache not
empty.
Once the cache is empty, the device frees it and stops running the
periodic GC.
This is for 3 reasons:
1. Separation of concerns
The device is meant to manage the Vulkan/GL device and check stuff
like image sizes.
Caching is not part of that.
2. Refcounting
Images etc want to reference the device, but the cache wants to
reference images. If the cache is the device, that's a refcycle.
3. Flexibility
It's now easier to implement >1 cache, say one per depth or one per
color state.
If we unparent the widget, we should sever a11y relations too.
Otherwise, an a11y implementation might follow them and be surprised
to find a parentless widget (and not in a good way).
Updated tests to not check the relation on an unexpanded expander.
The unary (closure) annotation is for function pointer types; function
arguments that represent the user data to be passed to the callback are
annotated on the callback argument itself, with (closure arg-name).
Commit a4cc95b2 introduced a check in layout() that closes the popover
if the width or height is smaller than the minimum width or height,
respectively. However, that was using gtk_widget_get_preferred_size(),
which finds out the minimum height for the minimum width and vice versa,
but not the minimum height for the layout width and vice versa. So,
certain popovers were not showing, even though they would not have
generated a critical to begin with.
To fix this, we copy the logic from gtk_widget_allocate() that generates
the criticals, and use that to check if we have a good width/height for
the popover native or not.
Closes#6826
Commit b9487997 introduced shadows for GtkPopover. These are correctly
subtracted while allocating the child widget, but the child is not
measured with those shadows subtracted (as is correctly done for the
arrow). This can give criticals, for example with some wrapping labels.
To fix this, we subtract the shadow size from the `for_size` before
passing it to the measure() of the child widget.
Closes#5782Fixes#6796
The compare tests use an empty container node, but running them with
--replay ends up with empty nodes in snapshots due to how containers are
replayed.
Related: !7396
Related: #6761
Keeping the GdkRGBA requires doing later conversions, which isn't
necessary if we just keep the already converted float[4].
It also prepares for future color states, where the color will need to
be converted using the colorstate.
Fill and stroke nodes were not reporting proper offscreen-for-opacity
and preferred depth.
This was unlikely to have been noticed as their child is usually a solid
color.
Some of the properties where currentcolor might make a difference
between computed and used value are arrays, so we need to be able
to resolve arrays of values. Change things around to make resolve
a GtkCssValue vfunc and turn the existing resolve() implementations
into implementations of that vfunc.
Fixes: #6814
There is no way for callers of this function to find out if
the drop is still the same, so spewing a critical if it isn't
seems useless. Just quietly do nothing.
gtk_text_set_positions is the central place for any changes to
text caret and selection bound. And it already filters out no-change
updates. So move the remaining signals from
gtk_text_set_selection_bounds here, for more accurate updates
of cursor positions in accessibility.
Fixes: #6805
These tests check various situations with inheritance and
currentColor. In particular the caret-color test was not
working correctly before we handled used values explicitly.
The way this works is that we first apply the value changes
from animations, which will trigger recomputation of the regular
style properies if the keyframes contains custom properties.
After that is done, we resolve the used values, base on the
new computed values. This is where currentcolor is resolved.
Change the style computation machinery to populate the used
values struct, and stop relying on NULL values in the values
structs to indicate currentColor occurrences. Instead, use
gtk_css_color_value_contains_current_color() when determining
style changes.
Make gtk_css_color_value_resolve() handle situations where it can't
fully resolve a color expression. This will start to happen in the
next commits, when we make currentColor compute to itself
This commit also changes the api for gtk_css_color_value_resolve
to not take the property_id, since we already pass the currentcolor
value that it is meant to help determine. Update all callers.
Track whether a value contains currentcolor (in which case
it needs to be resolved at use time).
This just adds the bit and the getter, it isn't used yet.
When we look for what values need recomputing, we also determine what
value we are going to use to recompute. For values that contain
variables, that is the 'original' value, as returned by
gtk_css_style_get_original_value. For values that we recompute
because they may contain currentcolor, that is the specified value
as returned by gtk_css_animated_style_get_intrinsic_value.
The one issue here is that we currently don't preserve currentcolor
in the computed value, so recomputing the value does not do us
any good in the color case. That will be fixed separately.
The color property does not need recomputing here since we are
in the case where we know that the keyframes contain a color value.
And it is background-color, not background-image, that contains
the color for the background shorthand.
Determine whether the style needs recomputation, then recompute
the style, and then set the values from keyframes, so we don't
end up overwriting keyframe changes by recomputing properties from
their original values.
Fixes: #6807
The feature was apparently missing, as monitors were always fullscreened at the surface best monitor.
Keep using best monitor if the selected monitor is not specified, otherwise move the window to the selected monitor before going fullscreen.
Despite my best effort, it seems impossible to make ci and local
builds agree on what font subsetter and fonts to use, so make this
opt-in for now: If you want to produce a node file with embedded
fonts, set GSK_SUBSET_FONTS=1.
Add a custom fontconfig setup and ship Cantarell as part of it.
This should hopefully make it so that the tests always see the
same default font, as long as you have FONTCONFIG_FILE set up
correctly.
Update all affected tests.
The rendernode parser creates its own fontmap for the fonts that
we deserialize from blobs. But we were using the system fontconfig
configuration for it, leading to system fonts still being found.
This is bad, and causes test failures in ci. Try with an empty
fontconfig configuration instead.
On failures, don't immediately abort, just g_test_fail().
This allows running the test with -k to get full output.
Also print something useful as the error message, namely the bytes that
are different.
There's no benefit in having multiple windows share the process.
But there's a huge disadvantage because running the app a 2nd time with
different environment variables will open a window in the first process
instead and discard the variables.
And my use of GSK_RENDERER hates that.
Parse things like "in hsl hue longer". For details, see the
CSS Images Module Level 4, https://www.w3.org/TR/css-images-4.
This commit fixes preexisting brokenness in conic-gradient parsing
and printing as well, and includes the relevant test changes.
Tests included.
Gradient interpolation color spaces aren't supported for
rendering yet.
Parse things like "in hsl hue longer". For details, see the
CSS Images Module Level 4, https://www.w3.org/TR/css-images-4.
Tests included.
Gradient interpolation color spaces aren't supported for
rendering yet.
Parse things like "in hsl hue longer". For details, see the
CSS Images Module Level 4, https://www.w3.org/TR/css-images-4.
Tests included.
Gradient interpolation color spaces aren't supported for
rendering yet.
The code parsing interpolation methods hadn't learned about
or latest color space additions. While we're at it, improve
the error reporting a bit.
Tests included.
It needed to be added to the vendored XML introspection data, so it was not
marked by a GDBus client as missing outright, and the comparison in the
property handler was also wrong.
gdk_vulkan_context_check_swapchain uses priv->current_format,
so we must update it first, and undo that if check_swapchain
falls. This fixes handling of high-depth back buffers in gsk.
This is useful in debugging.
The names I chose are shortened a bit from the enum values. We
use just a single depth, * for premultiplied, and f for float.
Since GskTransform is immutable, a lot of the documented "methods" are
more like "functions", in the sense that they don't keep the instance
alive but rather consume it.
This is annotated with `(transfer full)`, but since these functions are
listed as methods, their first argument is not shown.
Instead, let's add a line to the docs of each consuming function that
clarifies this behavior.
Parse the various color(from <color> ...) syntaxes, and implement
them.
Add a new 'relative color' subtype for color values, and a new
'color coord' subtype for number values. Use these for relative
colors where the original color can't be resolved at parse time.
We will need to compute other values in here in the future, and for
that we need all the arguments that get passed to compute(), so carry
them along.
Update all callers.
Even if we disable font fallback, after adding Cantarell Regular
to the custom fontmap, fontconfig will helpfully synthesize
Cantarell Bold for us. So, just don't check for the font at all.
If there is a url, add it to the fontmap and leave it up to the
serializing code to ensure that we don't end up with duplicate
fonts.
The hb face is is a wrapper around the font file, which is what
we need to track here, since we want to subset and serialize each
used font file exactly once.
When serializing nodes, collect the glyphs that are used from
each font, subset the font to that set of glyphs, and embed it
into the node file. We are careful to preserve the glyph IDs,
so our text nodes transparently work with the subsettted fonts.
Make color values carry their srgb equivalent and don't turn them
into literals at compute time. This is necessary so we can use their
original color space values in interpolation.
This makes color values a bit larger, but they still fit into one
cacheline.
We don't change handling of named colors and our color expressions.
They still get turned into literal colors.
Add support for parsing none for color components, and preserve
that information for serialization. We currently don't use it
for other things, but we should.
Clipping on padding box prevents the scale highlight to fully paint itself
over the scale trough, including its border.
Use the border box instead.
Fixes#6332
Clipping using OVERFLOW_HIDDEN relies on widget's padding box.
This prevents the highlight to paint itself over the trough's borders.
Use the border box instead, with a custom snapshot implementation.
Fixes#6332
Update the `GTK_ACCESSIBLE_PROPERTY_LABEL` property
in `gtk_label_set_text_internal` using the new text
instead of using the label in
`gtk_label_set_label_internal`.
While the `label` "includes any embedded underlines
indicating mnemonics and Pango markup" [1], the
`text` is the "text is as it appears on screen" [2],
which is more suitable for the accessible name.
With this in place, the text is reported as the
accessible name again after
commit d5b34aecdd
Date: Wed Jan 17 12:49:38 2024 +0100
a11y: Remove special handling of accessible names for static text widgets
[1] https://docs.gtk.org/gtk4/method.Label.get_label.html
[2] https://docs.gtk.org/gtk4/method.Label.get_text.htmlFixes: #6732Fixes: #6735
This way, we can simply duplicate the keys as separate pointers to store
the corresponding Vulkan handles so that we can safely hash them, as
Vulkan handles may or may not be pointers depending on the target
platform.
This will fix builds on 32-bit Windows at least.
VkShaderModule's may or may not be pointers depending on the target
platform, so use pointers to hash those handles to be safe, and retrieve
them from hashes accordingly.
Fixes build on 32-bit Windows at least.
1MB textures can lead to 20s runtimes - which with asan CI being a lot
slower can be a loooong time and cause timeouts.
Limiting them to 16kB still allows hitting max texture size sometimes
but makes sure the test only runs for 3-4s worst case.
I hope that doesn't trigger timeouts even under asan.
This function does not use the standard __cdecl calling convention on
Windows, meaning using g_clear_pointer() on it directly will cause
crashes on 32-bit Windows. Just call it directly if the GLsync it uses
exists.
Currently we only have sRGB, so it's a bit redundant, but we'll need this
for color-mix()
Once we have more color spaces, they should be added here (presumably the
enum would be in GDK instead, and instead of GdkRGBA these colors would
have a GdkColor.
This way, we can simply duplicate the keys as separate pointers to store
the corresponding Vulkan handles so that we can safely hash them, as
Vulkan handles may or may not be pointers depending on the target
platform.
This will fix builds on 32-bit Windows at least.
VkShaderModule's may or may not be pointers depending on the target
platform, so use pointers to hash those handles to be safe, and retrieve
them from hashes accordingly.
Fixes build on 32-bit Windows at least.
1MB textures can lead to 20s runtimes - which with asan CI being a lot
slower can be a loooong time and cause timeouts.
Limiting them to 16kB still allows hitting max texture size sometimes
but makes sure the test only runs for 3-4s worst case.
I hope that doesn't trigger timeouts even under asan.
This function does not use the standard __cdecl calling convention on
Windows, meaning using g_clear_pointer() on it directly will cause
crashes on 32-bit Windows. Just call it directly if the GLsync it uses
exists.
Update the `GTK_ACCESSIBLE_PROPERTY_LABEL` property
in `gtk_label_set_text_internal` using the new text
instead of using the label in
`gtk_label_set_label_internal`.
While the `label` "includes any embedded underlines
indicating mnemonics and Pango markup" [1], the
`text` is the "text is as it appears on screen" [2],
which is more suitable for the accessible name.
With this in place, the text is reported as the
accessible name again after
commit d5b34aecdd
Date: Wed Jan 17 12:49:38 2024 +0100
a11y: Remove special handling of accessible names for static text widgets
[1] https://docs.gtk.org/gtk4/method.Label.get_label.html
[2] https://docs.gtk.org/gtk4/method.Label.get_text.htmlFixes: #6732Fixes: #6735
As they are generated by gi-docgen thanks to the newly added async annotations.
It allows bindings that don't expose the _finish
functions to propose less-confusing docs
This protocol lifts some functionality from the gtk-shell protocol,
namely the ability to tag dialogs as modal. Ensure to use this
new protocol if available for the task, instead of the gtk-shell
protocol.
Make the info about the required protocols an array of definitions
again (a dict instead of an array this time) and add a field that
may be used for version checks of the wayland-protocols found.
Also, make it possible to have versioned protocols in-tree. Both
of these things will allow us to ship in-tree copies of wayland-protocols
without necessarily having to bump the version we depend on.
Here we calculate the length only in the truncate_multiline condition.
Then we pass pos - 1 to gtk_accessible_text_update_contents() as the end
position, triggering this critical that checks to ensure start <= end.
Fix it by always calculating the length of the string that we insert.
This is the first bug fixed as a result of enabling fatal criticals by
default in Epiphany! 🎉Fixes#6734
Make calc() work in colors too, since we need to support degrees for hsl()
hue anyway and it goes through the same machinery. Make that work for
legacy syntax too, matching the spec.
Ignore missing components/none for now.
Ignore gdk_rgba_parser_parse(), that's also used outside css.
Warn for uses of @name colors, since these should be replaced with
CSS variables and custom properties. We don't issue deprecation
warnings for @define-color uses, since we may want to keep these
around in theme CSS for a while, for backwards compatibility.
Update all affected tests.
gtk_css_parser_has_references is meant to be a quick check for
whether a property value contains a variable reference, it just
returns a boolean and doesn't need to report any errors, so lets
not parse the property value any more than we need to.
Don't trigger recomputation if the values didn't change. We only
do this for custom values, since those are animated with a flip
at 50%, so it is likely that we see no-change updates.
Pass a reason into gtk_css_animated_style_recompute, and avoid
recomputing properties that aren't affected. The possible reasons
for now are that variables of color changes. Better tracking
for currentColor in properties will allow us to improve this
later.
Implement the functions described in the "Mathematical
Expressions" section of the "CSS Values and Units Module
Level 4" spec, https://www.w3.org/TR/css-values-4/.
Beyond calc(), which we already had, this includes
min(), max(), clamp(),
round(), rem(), mod(),
sin(), cos(), tan(), asin(), acos(), atan(), atan2(),
pow(), sqrt(), hypot(), log(), exp(),
abs(), sign(),
e, pi, infinity and NaN.
Some tests included.
Allows the application to handle "Dock icon > Quit" the same as
"Application menu > Quit".
Requires GtkApplication's `register-session` property.
Suitable replacement for gtk-mac-integration's
`NSApplicationBlockTermination` signal.
Extract the "user filter" code from the `GtkFontChooserWidget`, for a
couple of reasons:
* If we want to expand the filter in the future (e.g. to filter on
variable fonts, or check for multiple languages), we have a nice place
to put this.
* It simplifies the font chooser widget a tiny bit, as it's a pretty big
file which can be hard to follow.
* With a custom `GtkFilter` subclass, we can actually avoid doing a bit
of work when initially showing the widget, as we can return
`GTK_FILTER_MATCH_ALL` when nothing is selected yet (which is not
possible with a `GtkCustomFilter'). It's not much, but it's still nice
'XPointerUngrabInfo' appears unused since
commit 26cbf87d7d ("New approach for grab tracking code")
Remove it.
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
Copy what gcc's libstdc++ does for vectors to avoid overflows:
1. Define a max size macro and assert against it
Note that we don't assert but actually check, because this needs
to abort even if assertions are disabled.
2. Don't do fancy math to compute new capacity.
Just size *= 2 instead and be careful about overflow.
Emit errors for all the variables that were being expanded
if an error occurs while parsing a property value at compute time.
Include the variables that are being expanded in the error message.
Pass the bytes we're parsing to the sections, and keep a pointer
to them around, so we can compare them in the has_section
implementation.
This commit also corrects some of the location information that
we add into the section for variables to be more accurate.
We were doing it in one case, but forgetting it in another.
These sections are necessary to report meaningful error locations
when parsing property values at compute time.
When we compute values, the provider we use ends up being the
style cascade. If we hit a parser error when parsing variable-bearing
property values at compute time, we emit the error on that provider.
By making the cascade propagate the error back to the proper css
provider that contains the section in question, we get it reported
back to the css editor in the inspector.
This will be necessary for supporting variables in animations.
For this we need to pass all the gtk_css_value_compute() parameters into
GtkCssAnimatedStyle: parent style and provider.
We'll need this to support variables in @keyframes, since styles will
need to combine their own variables and the ones from the keyframes.
See the next commit, this one is split out to avoid a huge diff.
Switch symbolc icon drawing from color-matrix to mask nodes
make the performance of the iconscroll demo crater (from 60fps
to 10fps).
Apply the same optimization we already have for color-matrix
nodes when drawing mask nodes. This gets us back to 60fps.
Fixes: #6700
Due to an ARAY vs ARRAY mishap, we weren't actually preallocating
any blocks. Fix that, and reduce the number of preallocated blocks
to 12. That seems sufficient, since parsing the Default theme never
needs more than 5 blocks.
When changing the tooltip text or markup of widget A, we simulate a
motion event on that widget to update the display.
But if there is an active tooltip on widget B, then the current code
belives we moved the pointer from B to A thus hides/shows the tooltip
of B alternatively.
Instead, simulate the motion event on the widget currently under the pointer.
This will avoid flickering if we keep the pointer over widget B.
Fixes#6674Closes#6674
In case the context's only reference was held by being the current
context, setting the new context would free it.
Resetting it later would then be a use-after-free.
Fixes#6694
Currently, GTK does not check the result of vkAcquireNextImageKHR() and
assumes that it always succeeds. As a result, the vkQueuePresentKHR() is
unconditionally set to wait for the semaphore passed to
vkAcquireNextImageKHR() earlier.
However, if vkAcquireNextImageKHR() fails for some reason, the semaphore
passed to it does not get signalled. This causes the presentation
command to wait for the semaphore to be signalled indefinitely, which
causes GTK to hang.
This change adds error handling around vkAcquireNextImageKHR() to make
GTK recreate the Vulkan swapchain when it is necessary or beneficial and
helps avoiding situations that could cause indefinite waits.
The docs for GtkBuilderListItemFactory previously stated that the
template must extend GtkListItem. However, this is not always true.
GtkListView has headers which must extend GtkListHeader, and
GtkColumnView has its own types.
Clarified this in the GtkBuilderListItemFactory docs, and specified the
expected types in the GtkColumnView, GtkListView, and GtkGridView docs.
On Windows, gsize is a long long unsigned. The compiler complains about
that.
Use G_GSIZE_FORMAT which translates to %llu on Windows, %lu on most
platforms, and sometimes just %u on rare cases.
This reverts commit 84a304e66e.
This produces marks that are confusing to me. They don't correlate
with actual gaps in the frame cycle and often overlap with regular
'window presented' marks. Also, the function we are emitting these
marks from is called from the get_frame_time getter, and we
definitely don't want to emit marks from there.
GTK_ACCESSIBLE_ROLE_GENERIC is for
"a nameless container that has no semantic meaning of its own",
for which AT-SPI role ATSPI_ROLE_PANEL [1]
("A generic container that is often used to group
objects.") fits better than ATSPI_ROLE_FILLER
("A object that fills up space in a user interface."),
so map to this one.
With this in place, widgets like GtkBox are again
reported with the panel role on AT-SPI level after
commit a86923de94
("a11y: Change the role for many containers"),
whose commit message suggests that the change
on the AT-SPI level was unintended.
For GTK_ACCESSIBLE_ROLE_GROUP, use the corresponding
ATSPI_ROLE_GROUPING ("A group of related widgets.
This group typically has a label.").
[1] https://docs.gtk.org/atspi2/enum.Role.html
In order for the size change check to make sense, vk_pipeline_cache_size
needs to correspond to the size of the cache we last wrote to disk.
We were forgetting to update it after saving the cache, so the
check was ineffective.
If the svg doesn't use the symbolic style classes, we can avoid
loading it multiple times.
This brought the time for loading system-run-symbolic at 256@2
from 6.8ms down to 2ms.
Add an 'only_fg' argument to all our internal texture utility
api, so GtkIconTheme can find out if a symbolic png or svg uses
colors beyond the foreground or not.
This information is used in gtk_symbolic_paintable_snapshot_symbolic
to optimize rendering of such symbolic icons.
We want to store some metadata in our symbolic pngs, so make it
possible to get options when loading a png, along with the texture.
Update all callers.
In particular, add all the dmabuf texture details.
I originally wanted this just to see if a texture was the type I
expected it to be while debugging, but then I thought "why not add the
rest, too?"
I did not add GL-internal texture details (like GL format,
internalformat etc), because that would require a make_current().
Use different codepaths for known formats vs unknown formats.
Be more careful with unknown formats and always import them as
GL_TEXTURE_EXTERNAL_OES when possible (GL can't do EXTERNAL) to avoid
problems.
This is a more defensive approach towards older drivers that don't
support modifiers.
This fixes importing YUV textures on AMD Gen8.
Another approach would be to check for YUV and never try
GL_TEXTURE_2D with them, but I decided to go this way first.
Fixes#6668
Due to rounding errors, it is possible after intersecting a lot of
rectangles to end up with a tiny size for an offscreen. And because we
allow an epsilon before ceil()ing to an integer (see commit afc7b46264
for details) it is now possible that we end up with a size of 0.
Avoid that by always enforcing a minimum size of 1px.
Test included
The test uses a different codepath to arrive at the same problem - it
specifies the small size instead of triggering it via rounding errors
and clipping like the original bug (and most likely the more common case
to encounter this problem.
Fixes#6656
Use a format of
[XXX] SYMBOL DETAILS
where SYMBOL indicates the offloading status:
🗙 - no offload
▲ - offload above, with background
△ - offload above, no background
▼ - offload below, with background
▽ - offload below, no background
The VK_IMAGE_LAYOUT_UNDEFINED layout means that the data hold by the
texture can be discarded, and we don't want to discard it. Because the
Vulkan spec is unclear (see [1] for a discussion), err on the side of
caution and use VK_IMAGE_LAYOUT_GENERAL.
Fixes import failures with WebKit.
[1] https://github.com/ValveSoftware/gamescope/issues/356
For completeness' sake, also specifiy in the PIXELFORMATDESCRIPTOR to use no
depth, stencil and accum bits to initializing WGL when we can't (yet) use
wglChoosePixelFormatARB(), as we must always fist have a base legacy WGL
context using ChoosePixelFormat() before we can use that to use
wglChoosePixelFormatARB(), or if wglChoosePixelFormatARB() is somehow not
available for us.
Some drivers, however, enforces enabling depth buffers, so if we can't
acquire a pixel format that disables depth buffers, retry acquiring one
with that, which sadly is not optimal but we must make do.
Attempts to complete fix for issue #6401.
Visual Studio (and possibly other non-GCC compilers) do not like
uses of #-preprocessor directives in macro usage (warning C5101: use of
preprocessor directive in function-like macro argument list is undefined
behavior is also shown), so fix the build by defining another macro
accordingly.
This adds support for setting a string used to describe the operation of a control,
if there's something special about it.
This is mapped to the HelpText property in the AT-SPI2 backend,
and has equivalent in others.
Popping an event of the queue in the IMContext handler
prevents it from being forwarded to the NSApp, in case the
(key) event was not handled by IMContext.
So I reverted to a mix of the original (4.13) and new (4.14.1) behavior
for fetching events: NSEvent lookup for IMContext uses loose matching,
so it can work with rewritten events. When sending events to NSApp, only
we're checking for an exact match.
Now in-app keyboard shortcuts (e.g. Ctrl-F2) work from within text
fields again.
We prefer it over the old DESKTOP_STARTUP_ID environment variable if we
have it and it is valid.
We have to stash and unset XDG_ACTIVATION_TOKEN in addition to
DESKTOP_STARTUP_ID now as well. This makes sure that we don't call any
library functions which might rely on some environment variables. This
way unsetting the environment variables is safe and we can then
afterwards validate and print warnings.
in the old approach it was possible that one NSEvent was
sent to the underlying NSApp multiple times. This resulted in
those events being forwarded to our (glib) event queue again.
The visual result was that no screen updates were done. Under the hood
the application was very busy with passing events around.
By popping the events off of our event queue, we make sure they're sent
only once.
Do the same checks for background coordinates that we do for the
subsurface coordinates themselves: they must be integral in both
application and device pixels.
Spew a bit less per-frame. Unfortunately, we still spew for
every frame, and fixing that would require more extensive
refactoring to centralize all logging in gskoffload.c
These cause harm in connection with subprojects if the subprojects
yield to a deprecated option. So just rip the bandaid off and
drop the deprecated build options.
A floating reference is returned, not a full reference. By having no
annotation, like for all other widget constructors, the correct default
is used again.
For now, this just applies the shadow from the widget's style,
there is no way to apply different shadows to text ranges (except
for the selection, which already has its own css style).
The intent of this change to get wider testing and verify that the
Vulkan drivers we get to use in the wild are good enough for our
needs. If significant problems show up, we will revert this change
for 4.16.
The new preference order is vulkan > ngl > gl > cairo.
The gl renderer is still there because we need it to support gles2.
If you need to override the default renderer choice, you can
still use the GSK_RENDERER environment variable.
Fixes: #6537
Replace the font options with the new font rendering setting.
The font options are still available for tweaking in the inspector
as properties of the GtkSettings object.
Add a high-level setting that gives us more freedom to tweak
font rendering knobs according to our needs. It has a 'manual'
value that lets users continue to influence font rendering using
the low-level font-related settings as before.
Once the schemas have this, we can support setting this session-wide.
See https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/-/merge_requests/79
The initial implementation of 'automatic' font rendering is fairly
simplistic: if the monitor dpi is less than 200, prefer sharpness,
so turn on metrics hinting and slight hinting. If the monitor dpi
is at least 200, we both off.
Change the default value to TRUE. This is because we want to stop
hardcoding this value for unscaled situations, but we don't want
to change everybody's font rendering.
GdkVulkanContext is deprecated and only exposed in the api because
we need it as return type of the (deprecated)
gdk_surface_create_vulkan_context() API.
This property allows explicit control over whether to draw
a black background behind offloaded content or not, instead
of relying on the theme background.
In fetch_net_wm_check_window(), before updating the wmspec_check_window, a
check is performed to verify a 15s difference between last_wmspec_check_time
and the current monotonic time.
The comment suggests that this check is done to ensure that it doesn't check
for a new check window repeatedly over and over again. While that was the case
origionally, currently the last_wmspec_check_time only gets updated when
wmspec_check_window is set, which is already checked earlier, making the time
check useless.
This check causes issues on cold boots where gtk4 applications are not able
to obtain the wmspec_check_window until 15 seconds after boot, making gtk
unable to check for extended wm_hints during that time.
Fixes: #6558
Do the backend call before changing the stacking order in the
frontend. This is necessary so the backend can look at the current
stacking order to determine if it will change.
Only commit things that have changed. In the ideal scenario, only
the texture changes from frame to frame, and all the sizing related
setup and the background stay the same, causing the least amount
of work in the compositor.
Rename things so they make more sense. The dest/source naming got
a bit unclear when we added background into the mix. Now we're going
for:
source_rect - the texture region to display
texture_rect - dimensions of the subsurface showing the texture
background_rect - dimensions of the background subsurface
bounds - union of texture_rect and background_rect
Also use this opportunity to add some api docs.
Detect a black color node below the texture node and pass that
information to the subsurface, to take advange of the single-pixel
buffer optimization.
To make this work, we need to stop using the bounds of the subsurface
node for sizing the offload, and instead use either the clip or
the texture node for that.
Make it possible for subsurfaces to have a black background on a
secondary subsurface below the actual subsurface. Using a single-pixel
buffer for that background increases the changes that the compositor
will use direct scanout for the actual subsurface.
This changes the private subsurface API. All callers have been
updated to pass an empty background rect.
This is useful for debugging offloading without having to rely
on gstreamer giving us dmabufs. To use it, set
GDK_DEBUG=force-offload
in the environment.
- Fix link to the security policy
- Drop the confusing note about SSH access (with the old URL)
- Use modern idiomatic Meson subcommands for configuring and building
- Use `git switch` instead of `git checkout`
- Specify that you should always use merge requests, not patches
- Link to the handbook instead of the wiki
The compiler (gcc 13.2) thinks that `t` could be used uninitialised.
That’s obviously not the case, because there’s always going to be at
least one loop iteration due to the initial values of `t1` and `t2`.
Change the loop to a `do…while` to make that a bit clearer to the
compiler without making any functional changes to the code.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
If there somehow end up being no `supported_versions`, `ctx` would end
up being dereferenced before being initialised. While I think that’s
unlikely, the compiler doesn’t know that, so let’s just initialise the
variable unconditionally.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
We were getting our gl and dmabuf texture mixed up and ending
up freeing the Texture structs while they were still used as
callback data for dmabuf texture destroys. Avoid that by keeping
separate pointers for the gl and dmabuf textures.
Fixes: #6623
The goal is to generate an offscreen at 1x scale.
When not ceil()ing the numbers the offscreen code would do it *and*
adjust the scale accordingly, so we'd end up with something like a
1.01x scale.
And that would cause the code to reenter this codepath with the goal to
generate an offscreen at 1x scale.
And indeed, this would lead to infinite recursion.
Tests included.
Fixes#6553
The parsing for a `GTK_TYPE_SHORTCUT_ACTION` on a GtkShortcut in a
builder file can fail, resulting in a `NULL` GtkShortcutAction. This
currently does not result in any warnings, potentially making typos in
builder files tricky to debug.
Since `gtk_shortcut_action_parse_builder()` already sets an error if it
fails, we can just use that and simply return false.
This drops cursor and eraser source names to account for their removal
from GdkInputSource so that GDK_DEBUG=input debug message correctly
prints source type in X11 environment.
Fixes: c1d90273 ("gdk: Drop GDK_SOURCE_ERASER")
Fixes: 3285f52d ("gdk: Drop GDK_SOURCE_CURSOR")
Closes: #6619
When we look for the texture to attach to the subsurface, keep
track of transforms we see along the way, and look at their scale
component to determine if the texture needs to be flipped.
We currently don't allow rotations here.
This fixes glarea rendering being upside-down when offloaded.
Allow to specify a D₂ transform when attaching a texture to a
subsurface, to handle flipped and rotated content. The Wayland
implementation handles these transforms by setting a buffer
transform on the subsurface.
All callers have been updated to pass GDK_TEXTURE_TRANSFORM_NORMAL.
GtkShortcutManager allows adding controllers to it. For the default
implementation, they get added to one of two models, based on the
propagation phase (either GTK_PHASE_CAPTURE or GTK_PHASE_BUBBLE).
However, when a controller is removed, its presence in the manager gets
checked against the current propagation phase of the controller, which
may have changed from when it was added. This can lead to crashes if the
controller was not disposed properly since it still has a reference in
one of the two models of the GtkShortcutManager.
To fix this, add a callback for `notify::propagation-phase`, which
removes the controller from all possible models and readds it again with
its current phase. This callback is only disconnected permanently when
the controller is manually removed with
`gtk_shortcut_manager_default_remove_controller()`.
Closes#6246
Remove duplicate descriptions of the switch's appearance, describe more
particularly how the default signal handler for `GtkSwitch::state-set`
behaves, and add a suggestion that the `state` property should
only be set when communicating a delayed state change.
Fixes#6600
This reverts commit 3d898af736.
The commit caused a regression where, depending on the update policy,
we would not apply value changes at all.
Fixes: #6599
Use the existing `gtk_at_spi_translate_coordinates_to_accessible`
to translate the coordinates passed as parameters to AT-SPI
Text's GetOffsetAtPoint method instead of having a
custom GtkWidget-specific translation.
This makes this work for non-GtkWidget GtkAccessibles
as well, and also adds support for parent-relative
coordinates (ATSPI_COORD_TYPE_PARENT).
With the fix from the previous commit in place,
trying to use the GetOffsetAtPoint AT-SPI Text method
from Accerciser's IPython console with the gtk4-demo
Hypertext example would still give this error:
In [46]: acc.queryText().getCharacterExtents(5, pyatspi.XY_WINDOW)
Out[46]: (58, 20, 5, 19)
In [47]: acc.queryText().getOffsetAtPoint(59, 21, pyatspi.XY_WINDOW)
---------------------------------------------------------------------------
Error Traceback (most recent call last)
Cell In[47], line 1
----> 1 acc.queryText().getOffsetAtPoint(59, 21, pyatspi.XY_WINDOW)
File /usr/lib/python3/dist-packages/pyatspi/text.py:346, in Text.getOffsetAtPoint(self, x, y, coordType)
331 def getOffsetAtPoint(self, x, y, coordType):
332 """
333 Get the offset of the character at a given onscreen coordinate.
334 The coordinate system used to interpret x and y is determined
(...)
344 -1 if the point is outside the bounds of any glyph.
345 """
--> 346 return Atspi.Text.get_offset_at_point(self.obj, x, y, coordType)
Error: atspi_error: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. (1)
and the gtk4-demo output would show the actual problem:
(gtk4-demo:563491): GLib-GIO-WARNING **: 13:18:27.652: Type of return value is incorrect: expected '(i)', got '(u)'
Fix this by returning an int as expected.
With this in place, the result is now as expected:
In [48]: acc.queryText().getCharacterExtents(5, pyatspi.XY_WINDOW)
Out[48]: (58, 20, 5, 19)
In [49]: acc.queryText().getOffsetAtPoint(59, 21, pyatspi.XY_WINDOW)
Out[49]: 5
Trying to use the AT-SPI Text GetOffsetAtPoint method
didn't work.
For example, trying to use it from Accerciser's IPython
console with the gtk4-demo Hypertext example, would
give this error:
In [45]: acc.queryText().getOffsetAtPoint(59, 21, pyatspi.XY_WINDOW)
---------------------------------------------------------------------------
Error Traceback (most recent call last)
Cell In[45], line 1
----> 1 acc.queryText().getOffsetAtPoint(59, 21, pyatspi.XY_WINDOW)
File /usr/lib/python3/dist-packages/pyatspi/text.py:346, in Text.getOffsetAtPoint(self, x, y, coordType)
331 def getOffsetAtPoint(self, x, y, coordType):
332 """
333 Get the offset of the character at a given onscreen coordinate.
334 The coordinate system used to interpret x and y is determined
(...)
344 -1 if the point is outside the bounds of any glyph.
345 """
--> 346 return Atspi.Text.get_offset_at_point(self.obj, x, y, coordType)
Error: atspi_error: Unsupported coordinate space (1)
and the gtk4-demo output would show the actual problem:
(gtk4-demo:562820): GLib-CRITICAL **: 13:14:10.862: the GVariant format string '(i&s)' has a type of '(is)' but the given value has a type of '(iiu)'
(gtk4-demo:562820): GLib-CRITICAL **: 13:14:10.863: g_variant_get: assertion 'valid_format_string (format_string, TRUE, value)' failed
Specify the proper type, which gets us one step further at least.
Instead of reimplementing translating coordinates
relative to a GtkAccessible in a way that requires
that the GtkAccessible is a GtkWidget, reuse the
existing helper function
`gtk_at_spi_translate_coordinates_from_accessible`
in the implementations of AT-SPI Text methods
GetCharacterExtents and GetRangeExtents.
This makes the implementation work for non-GtkWidget
GtkAccessibles, adds support for parent-relative
coordinates (ATSPI_COORD_TYPE_PARENT)
and also fixes an issue with incorrect extents
being reported in a quick test with the "Hypertext"
sample from gtk4-demo.
Sample for querying extents in Accerciser's IPython
console for the Hypertext sample previously gave this
result:
In [39]: acc.queryText().getCharacterExtents(5, pyatspi.XY_WINDOW)
Out[39]: (58, 20, -53, -1)
Now, a positive width and height are returned as expected and
the result matches the one when using the GTK 3 version
in gtk3-demo:
In [1]: acc.queryText().getCharacterExtents(5, pyatspi.XY_WINDOW)
Out[1]: (58, 20, 5, 19)
Move the (so far) local helper functions used for the
AT-SPI Component method implementations,
`translate_coordinates_from_accessible` and
`translate_coordinates_to_accessible` to
`gtkatspiutilsprivate` and add a "gtk_at_spi_"
prefix to the function names.
This will allow to reuse them elsewhere in
upcoming commits.
We still keep the editable implementation, since not all our
editable widgets implement GtkAccessibleText yet, but the label,
inscription and textview implementations are unused.
This should give us more flexibility for buffer size vs surface
size.
Unfortunately, mutter doesn't play along currently, so this is
only useful for kwin, weston or sway.
This app has a dynamic cursor that is the GTK logo, loaded from
an SVG to make it come out at the nominal size of the cursor
theme, while taking fractional scaling into account.
Add a variant of GdkCursor that obtains the texture for the cursor
via a callback. The callback gives us the flexibility to handle
fractional scales and update the cursor for cursor theme size
changes as well as scale changes.
There is some question if this needs to be clipped to widget extents
- if the textview is in a scrolled window, we can easily return
extents here that go beyond the window or event the screen.
This works better for cff fonts, where hinting is not as local as
what the autohinter does for ttf fonts, and it does not seem to
have negative effects.
Fixes: #6577Fixes: #6568
It turns out that we mispositioned glyphs with some cff fonts
when metrics hinting is off, and hinting is on. Since we don't
fully understand the interactions of these settings at this point,
lets preserve metrics hinting as it was on the font we got.
This at least gives folks a workaround for when they experience
clipped rendering with cff fonts: Turn on hint-metrics.
We forced hint metrics off here because it made Pango do some
creative wfh for hex boxes at small sizes, but I've dropped that
on the Pango side.
This attempts to improve the accuracy for the "presentation_time" of an
individual GdkFrameTimings. That information is currently filled in as soon
as we get a frame callback. However, if presentation-time wayland protocol
is available, that will be used to supliment a more accurate time which
may improve future presentation-time predictions within GdkFrameClockIdle.
The protocol states that all related and sub surfaces will receive the
same information so it is safe that this could be registered for more
than just the toplevel. The information becomes idempotent.
When no action is selected, use the default cursor, and only
switch to one of the action-indicating cursors when we are over
a drop target.
Fixes: #6337Fixes: #6511
This ensures that the separators are made visible before a popover
menu is shown. Previously the menu would jump in size after it
appeared.
Closes https://gitlab.gnome.org/GNOME/gtk/-/issues/5166
Map GTK_ACCESSIBLE_PROPERTY_LEVEL to the corresponding
AT-SPI object attribute "level", as it is specified
e.g. in the Core Accessibility Mappings 1.2 for the
"aria-level" attribute, for both, headings [1] and
non-headings [2].
This e.g. makes reporting the header level via
AT-SPI work for the gtk4-based LibreOffice variant
when combined with the corresponding LibreOffice
change [3] to set the GTK_ACCESSIBLE_PROPERTY_LEVEL
property.
For a related discussion, see issue #6196.
[1] https://www.w3.org/TR/core-aam-1.2/#ariaLevelHeading
[2] https://www.w3.org/TR/core-aam-1.2/#ariaLevel
[3] https://gerrit.libreoffice.org/c/core/+/159216
When grabbing the seat for an xdg popup using xdg_popup_grab() in response
to a touch-end event, we request the grab a little late and the touch is no
longer being tracked by gdkseat. This means that
_gdk_wayland_seat_get_last_implicit_grab_serial() right now can not provide
us with the serial for that touchpoint, because that serial was stored on
the GdkWaylandTouchData that is already gone.
To still provide the compositor a valid serial in that case, store the
serial of the latest touchpoint more persistently in GdkWaylandSeat itself,
so that we can still access it when the touchpoint has already ended.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
