| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Look also for pthread.h if threading support is found by Meson, as the
underlying threading support may not be PThreads, depending on platform.
For now, disable the thread-test test program if pthread.h and if
necessary, the PThreads library, cannot be found, as the current
implementation assumes the use of PThreads.
Also bump the required Meson version to 0.50.0 since we need it for
-cc.get_argument_syntax()
-For a later commit, the has_headers sub-method for cc.find_library()
|
|
|
|
|
|
|
| |
The implementation of OpenMP is not compliant for our uses, so disable
it for now by just not checking for it on MSVC builds, as we implicitly
add an /openmp switch to the build, which will cause linking the tests
programs to fail, as the OpenMP implementation is not enough.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-For MSVC builds, do not use the GCC-specific CFlags when checking for
these features.
-For the MMX check, assume that we have good enough MMX intrinsics and
inline assembly support (on ix86), since MSVC provides sufficient
support for those since before the times of MSVC 2008, and 2008 is the
oldest version that we can support, as with the pre-C99 GTK+ stack.
Unfortunately due to x64 compiler issues, pre-Visual Studio 2010 will
crash when building SSSE3 code, so we do not enable building SSSE3 code
on pre-2010 Visual Studio.
Also, for all x64 Visual Studio builds, we do not enable USE_X86_MMX
as inline assembly is not allowed for x64 Visual Studio builds, and
instead use the compatibility instrinsics that we already have in the
code.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Does not make the test pass, but does fix this error:
../test/stress-test.c:538:25: runtime error: signed integer overflow: 2147483647 - -2 cannot be represented in type 'int'
|
|
|
|
| |
../pixman/pixman-matrix.c:276:35: runtime error: left shift of negative value -32768
|
|
|
|
| |
../pixman/pixman-bits-image.c:678:33: runtime error: left shift of negative value -32768
|
|
|
|
| |
../pixman/pixman-bits-image.c:221:20: runtime error: left shift of 204 by 24 places cannot be represented in type 'int'
|
|
|
|
| |
../pixman/pixman-fast-path.c:3089:23: runtime error: left shift of 154 by 24 places cannot be represented in type 'int'
|
|
|
|
| |
../pixman/pixman-sse2.c:3346:14: runtime error: left shift of 41891 by 16 places cannot be represented in type 'int'
|
|
|
|
| |
../pixman/pixman-gradient-walker.c:216:35: runtime error: left shift of 163 by 24 places cannot be represented in type 'int'
|
|
|
|
| |
../pixman/pixman-image.c:963:46: runtime error: left shift of 255 by 24 places cannot be represented in type 'int'
|
|
|
|
|
|
|
|
| |
../pixman/pixman-combine32.c:657:1: runtime error: left shift of 128 by 24 places cannot be represented in type 'int'
../pixman/pixman-combine32.c:694:1: runtime error: left shift of 232 by 24 places cannot be represented in type 'int'
../pixman/pixman-combine32.c:712:1: runtime error: left shift of 255 by 24 places cannot be represented in type 'int'
../pixman/pixman-combine32.c:786:1: runtime error: left shift of 255 by 24 places cannot be represented in type 'int'
../pixman/pixman-combine32.c:805:1: runtime error: left shift of 255 by 24 places cannot be represented in type 'int'
|
|
|
|
|
|
| |
../pixman/pixman-access.c:389:2: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
../pixman/pixman-access.c:1101:2: runtime error: left shift of 2 by 30 places cannot be represented in type 'int'
../pixman/pixman-access.c:1152:2: runtime error: left shift of 2 by 30 places cannot be represented in type 'int'
|
|
|
|
| |
../pixman/pixman-utils.c:216:14: runtime error: left shift of 255 by 24 places cannot be represented in type 'int'
|
|
|
|
| |
../test/utils.c:2070:57: runtime error: left shift of 255 by 24 places cannot be represented in type 'int'
|
|
|
|
| |
../test/affine-test.c:174:34: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
|
|
|
| |
Reported in https://bugzilla.mozilla.org/show_bug.cgi?id=1580352. Casting the argument to uint32_t should avoid invoking undefined behavior here. We'll still have *implementation-defined* behavior when casting the result back to pixman_fixed_t, but that's better than *undefined*.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Meson doesn't do the expected thing when library() creates a static
library. Instead of combining the libraries together into a single
archive it effectively discards them, resulting in missing symbols.
To work around this we manually unpack the archives and shove the .o
files into the final library. This doesn't affect the shared library at
all, but makes the static library have the necessary symbols
Fixes #33
|
|
|
|
|
| |
To avoid potential signed integer overflow (undefined behavior), as implicit integer promotion means the operand becomes a (signed) int.
(Issue originally reported at https://bugzilla.mozilla.org/show_bug.cgi?id=1577669)
|
|
|
|
|
|
|
|
|
|
| |
GCC on Windows complains that "__declspec(thread)" doesn't work, but still
compiles it, so the meson check doesn't work. The warning printed by gcc:
"warning: 'thread' attribute directive ignored [-Wattributes]"
Pass -Werror=attributes to make the check fail instead.
This fixes the test suite (minus gtk tests) on Windows with mingw.
|
|
|
|
|
|
|
|
| |
So that passing "-Ddefault_library=both" also creates a static lib.
Note that Libs.private in the .pc file will still be wrong because of
https://github.com/mesonbuild/meson/issues/3934 (it contains things like
-lpixman-mmx)
|
|
|
|
| |
meson builds defaulted to SIZEOF_LONG=0 in various places
|
|
|
|
|
|
|
|
|
|
|
|
| |
The dithering code (specifically `dither_factor_bayer_8`) uses a GNU
extension for binary notation, eg 0b001. This is not supported by MSVC
(at least) and breaks the build on this platform [1].
This patches uses hexadecimal notation instead, fixing the build.
[1]: https://lists.freedesktop.org/archives/pixman/2019-June/004883.html
Reviewed-by: Matt Turner <mattst88@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On some screens (typically low quality laptop screens), using Bayer
ordered dithering has been observed to cause color changes depending on
*where the gradient is rendered on the screen*, causing visible
flickering when moving an image on the screen.
To alleviate the issue, this patch adds support for ordered dithering
using a 64x64 matrix tuned from blue noise. In addition to being devoid
of the positional dependency on screen, the blue noise matrix also
generates more pleasing and less discernable patterns. As such, it is
now the method used for PIXMAN_DITHER_GOOD and PIXMAN_DITHER_BEST
dithering methods.
The 64x64 blue noise matrix has been generated using the provided
`pixman/dither/make-blue-noise.c` script, which uses the
void-and-cluster method.
Changes since v1 (thanks Bill):
- Use uint16_t for the blue noise matrix for lower memory usage
- Use bitwise computation for array index
|
|
|
|
|
|
|
|
|
| |
This adds a dither.c which provides a demo of the dithering feature.
This is based on the scale.c demo for scaling and provides a selection
of intermediate formats and dithering operators (currently, only
PIXMAN_DITHER_ORDERED_BAYER_8) to use. Images are first blitted onto a
surface of the intermediate format with the requested dither setup, then
blitted back onto a a8r8g8b8 surface for display.
|
|
|
|
|
|
| |
This adds support for testing dithered destinations in tolerance-test.
When dithering is enabled, the pixel checker allows for an additional
quantization error.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements dithering in pixman. A "dither" property is added
to BITS images, which is used to:
- Force rendering to the image to go through the floating point
pipeline. Note that this is different from FAST_PATH_NARROW_FORMAT
as it should not enable the floating point pipeline when reading from
the image.
- Enable dithering in dest_write_back_wide. The dithering uses the
destination format to determine noise amplitude.
This does not change pixman's behavior when dithering is disabled (the
default).
Additional types and functions are added to the public API:
- The `pixman_dither_t` enum exposes the available dithering methods.
Currently a single dithering method based on 8x8 Bayer matrices is
implemented (PIXMAN_DITHER_ORDERED_BAYER_8). The PIXMAN_DITHER_FAST,
PIXMAN_DITHER_GOOD and PIXMAN_DITHER_BEST aliases are provided and
should be used to benefit from future specializations.
- The `pixman_image_set_dither` function allows to set the dithering
method to use when rendering to a bits image.
- The `pixman_image_set_dither_offset` function allows to set a
vertical and horizontal offsets for the dither matrix. This can be
used after scrolling to ensure a consistent spatial positioning of
the dither matrix.
Changes since previous version (v2):
- linear_gradient_is_horizontal optimization is still compatible with
the wide pipeline. The code disabling it was a remnant of a previous
patch which performed dithering directly inside linear_get_scanline,
and thus needed to be called independently for each scanline.
Changes since v1:
- Renamed PIXMAN_DITHER_BAYER_8 to PIXMAN_DITHER_ORDERED_BAYER_8
- Disable dithering for channels with 32bpp or more (since they can
represent exactly the wide values already). This makes the patches
compatible with the newly added floating point format.
Dithering is compatible with linear_gradient_is_horizontal
|
|
|
|
|
| |
Signed-off-by: Fan Jinke <fanjinke@hygon.cn>
Signed-off-by: Matt Turner <mattst88@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The recently introduced wide pipeline for filters has a typo which
causes it to improperly compute bilinear interpolation positions,
causing various glitches when enabled.
This patch uses the proper computation for bilinear interpolation in the
wide pipeline. It also makes related `if` statements conformant to the
CODING_STYLE:
* If a substatement spans multiple lines, then there must be braces
around it.
* If one substatement of an if statement has braces, then the other
must too.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
|
|
|
| |
Signed-off-by: Matt Turner <mattst88@gmail.com>
|
|
|
|
| |
Signed-off-by: Matt Turner <mattst88@gmail.com>
|
|
|
|
|
|
|
|
|
|
| |
These were forgotten in commit 0ea37df4286e (meson: store ARM SIMD and
NEON tests as text files) and since autotools doesn't use them make
distcheck still succeeded.
Fixes #30
Signed-off-by: Matt Turner <mattst88@gmail.com>
|
|
|
|
| |
Signed-off-by: Matt Turner <mattst88@gmail.com>
|
|
|
|
| |
Signed-off-by: Matt Turner <mattst88@gmail.com>
|
|
|
|
| |
Signed-off-by: Matt Turner <mattst88@gmail.com>
|
|
|
|
| |
Signed-off-by: Matt Turner <mattst88@gmail.com>
|
|
|
|
| |
Signed-off-by: Matt Turner <mattst88@gmail.com>
|
|
|
|
|
|
|
| |
When GNU Make is not from msys, the startup cost for sh.exe is massive
compared to cmd.exe.
Signed-off-by: Matt Turner <mattst88@gmail.com>
|
|
|
|
| |
Signed-off-by: Matt Turner <mattst88@gmail.com>
|
|
|
|
|
|
|
|
|
| |
This is unfortunately required to make the tests work correctly, as
otherwise meson assumes that the files are C code not assembly. I've
opened https://github.com/mesonbuild/meson/issues/5151, to discuss
fixing the issue in meson upstream.
Fixes #29
|
|
|
|
|
| |
This simplifies the logic and fixes the loongson-mmi implementation to
build correctly.
|
| |
|
|
|
|
| |
mentioned in #29
|
|
|
|
| |
mach -> march
|
|
|
|
|
|
|
| |
This issue causes openmp arguments to be injected into compilers that
can support openmp, even if they don't. This issue will be fixed in
0.51 (code already landed in mesonbuild#5116), for older versions lets
work around the issue.
|
|
|
|
|
|
| |
And update RELEASING for the new meson build system.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pixman-bits-image's wide helpers first obtains the 8-bits image,
then converts it to float. This destroys all the precision that
the wide path was offering.
Fix this by making get_pixel() take a pointer instead of returning
a value. Floating point will fill in a argb_t, while the 8-bits path
will fill a 32-bits ARGB value. This also requires writing a floating
point bilinear interpolator. With this change pixman can use the full
floating point precision internally in all paths.
Changes since v1:
- Make accum and reduce an argument to convolution functions,
to remove duplication.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Basile Clement <basile-pixman@clement.pm>
|