The default implementation for get_default_attributes() returns NULL for
both names and values yet the code which iterates them is assuming they
will never be NULL.
Since the interface implies that if the values are set, they will return
valid strings, make the default implementation do that.
Fixes: #7069
It seems that NVidia sets PFD_SWAP_EXCHANGE / WGL_SWAP_EXCHANGE_ARB
on pixel formats but doesn't guarantee that the backbuffer age is
constantly 2. My guess is that they use swap exchange only to signal
usage of a flip present method.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/7019
When changing the code to do the resize only when the size changed, I
forgot to queue a draw when the size did not change.
Fixes: 5031f30f28
Related: !7786
The warning gets triggered by rounding errors.
In particular when using fractional scales, the final tile may end up
not accurately matching the computed final value (in the example I was
debugging it was computing 1 vs 1.00000036 for the final tile index,
but that result computed a 0px wide tile size.
And for that tile size we hit that exit condition.
We get to create our GdkKey with a display as a property for free, so
just stuff the default keymap and keymap serial (to track IME state
changes and so) into our GdkWin32Display under an existing sub-struct
that is for holding these items.
On Windows, we really only support a single GdkDisplay, so we can just
make the GdkDisplay that we obtain a property of our GdkDeviceManagerWin32
and GdkWin32Screen objects, and so we can just do away with the global
_gdk_display global variable.
This way, we can also drop the venerable gdkglobals-win32.c source file.
Yay!
Instead, use [Set|Get]WindowLongPtr(), to store and retrieve that
value from the notification window HWND that we are using, as it
is where we are using that value.
Tuck the _win32_device_manager global variable into GdkWin32Display, and
drop the global variables that have to do with GdkDeviceManagerWin32.
Also improve how we query the WinPointer APIs from user32.dll, so that
we are sure that it is done once and only once.
Tuck the GdkWin32Clipdrop that we create in our GdkWin32Display, and
tuck the other associated global variables into GdkWin32ClipDrop and
GdkWin32Drag, as appropriate.
Also, since we are already registering "GDK_WORKER_THREAD_WAKEUP" as our
custom message to look for in our DND/clipboard ops, only register it
once, not twice, as it's not really necessary to do so since
RegisterWindowMessage() returns the same value for the same identifier
that is being used.,
Instead, record the current thread in the GdkDisplay, under a structure
for DND items, which will hold other relevant Windows Clipbord/DND global
variables.
Add a new function in gdkdrag-win32.c to check whether the current
thread is (or is not) equivilant to the thread that is initiated when
the GdkDisplay is initialized (which also returns true if there is no
GdkDisplay that is associated with the GdkDrag in question).
Rename gdkwin32id.c as gdkwin32misc.c.
Fold these items into GdkWin32Display, and also fold gdkproperty-win32.c
and gdkwin32langnoticiation.[c|h] into gdkwin32misc.c and gdkdisplay-win32.h as
appropriate.
This way, we get rid of few more global variables, and these items
should have been initialized (and registered with the system) when we
open a GdkWin32Display anyways.
Use the gdk_win32_surface_parent_class that is given to us by
G_DEFINE_TYPE() instead of using a global variable to store up the
parent class of GdkWin32Surface.
The original intent was to only realize parents recursively for
non-widget accessible objects. The implementation, however, always
try to realize parents. In the case of GtkStackPage, which is a
non-widget accessible with a widget accessible child, this breaks.
Only realize non-widget accessible parents recursively if the
current accessible is not a widget as well.
Closes https://gitlab.gnome.org/GNOME/gtk/-/issues/7058
Fixes 6074a18e3e
Add a uses-gl property to our sink implementation, and use
it in the paintable code. This avoids juggling a second gl
context, with the risk of leaking it.
Calling gtk_media_stream_realize is not mandatory, but we can
still try to make dmabufs happen. Tested by removing the realize
call from GtkVideo and using GDK_DISABLE=gl.
We only need a display to negotiate dmabuf formats. Pass that
directly, instead of getting the display of the GL context as
we did so far.
With this,
GSK_RENDERER=vulkan GL_DISABLE=gl gtk4-demo --run video_player
still uses dmabufs.
Related: #7048
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.
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.
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
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
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.
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.
When the item doesn't change and only the position / selection state,
then the signal list item factory should not emit bind + unbind signals.
This used to work, but probably broke while refactoring for ColumnView
during 4.10.
This caused excessive rebinding when items got inserted at the top of a
list instead of add the end.
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
2023-12-14 18:57:04 +00:00
702 changed files with 68126 additions and 36236 deletions
d="m 450.53751,-25.96846 c 0.24647,0 0.44708,0.19694 0.44708,0.44708 v 0.0289 c -0.008,3.05189 -2.48438,5.5237 -5.53812,5.5237 h -0.0148 c -0.25145,0 -0.44711,-0.20581 -0.44711,-0.4615 v -0.46152 -0.92302 c 0,-0.25567 0.20581,-0.4615 0.4615,-0.4615 h 0.92302 c 0.25569,0 0.46152,0.20581 0.46152,0.4615 v 0.21634 c 1.18002,-0.41715 2.10674,-1.34386 2.52389,-2.52388 h -0.21635 c -0.25566,0 -0.4615,-0.20581 -0.4615,-0.46152 v -0.92302 c 0,-0.25567 0.20581,-0.4615 0.4615,-0.4615 h 0.46152 0.4615 0.44709 0.0148 0.0148 z"
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.
