We were using it in all cases, so, we were using it to compute descriptions,
and also for non-embedded controls. That was overriding descriptions
set, for example, in Gnome settings, and was causing the value of spinboxes
to be read multiple times.
We really always want to force-include msvc_recommended_pragmas.h to check for
things at compile time so that we can avoid stuff like missing includes or
attempting to return a value in a function that is supposed to have a
void-return-type.
The current problem is that, as indicated in the Visual Studio CI job, that we
couldn't locate msvc_recommended_pragmas.h during the build if GLib is built
as a subproject, and/or when msvc_recommended_pragmas.h is not in the paths
indicated by %INCLUDE%, meaning that the aforementioned issues would not be
caught by CI, which will then break builds on Visual Studio for people when
msvc_recommended_pragmas.h is found during their builds.
It would also be nice to be quiet from the warnings that we can really
disregard anyways.
So, add a copy of msvc_recommended_pragmas.h from GLib and update the build
files to look for it in build-aux/msvc, so that it can always be used during
the build, especially by the CI.
Remove all the roadblocks we've put up to keep implicit modifiers
out. Our importing code already handles them as a signal that says
'No modifiers, please!'. Now we just hope for the best and pass
things along.
This is necessary since some drivers won't produce any explicit
modifiers.
Check that the right filter is chosen and that that filter is
implemented correctly.
The test is disabled for Cairo because Cairo (or rather Pixman)
doesn't follow the filtering specifications for GL/Vulkan and in
particular the nearest filter picks a different pixel.
Drawing a texture-scale node like a texture node when the filter is set
to "linear" doesn't work, because the texture node switches to
trilinear when mipmaps are available.
There is no reason not check the alpha swizzle for being different
from its default value. I am thinking about implementing RGBx
upload with a swizzle of rgb1, and that would break here.
We just poking at display members here, there is no guarantee that
dmabuf formats have been initialized. So do it explicitly.
This prevents a crash in the inspector when viewing a recorded frame
containing a dmabuf texture, since the inspector uses a separate
display connection.
We were confusingly printing "supported format" for dmabuf formats
that we end up not adding to our list of supported formats. Don't
do that, it is confusing. At the same time, we shuold print out
the linear formats we support via mmap.
If we can't open /dev/dma_heap/system, fall back to using memfd_create.
It does not let us make a 'proper' dmabuf, but it is good enough to
test our handling of linear buffers in various formats.
