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
