To add greater precision when working with transformed surfaces and/or
high-resolution input devices.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
We check that we get surface.enter_output and move the pointer into
the window and make sure we get input_device.pointer_enter with
the right coordinates.
There's a lot of code for a very simple test here, so we need to
figure out how to reuse most of the event handling and such. It's also
not clear that a custom, text based protocol is practical here, we might
just use a wayland extension after all.
There are no dependencies or requirements there that we don't already
need for weston itself. So lets just always build them.
Use check_PROGRAMS for the matrix unit test case.
Updates the .gitignore files for clients and tests to reflect a new test and a
couple of renamed applications.
Signed-off-by: Casey Dahlin <cdahlin@redhat.com>
We just set the input region to the bounding box of the window frame
and set the opaque region to be the opaque rectangle inside the window
if the child widget is opaque.
This test uses files from src/ so use COMPOSITOR_CFLAGS to find headers
in non-standard locations.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
The compositor will likely do an order of magnitude less matrix
inversions than point transformations with an inverse, hence we do not
really need the optimised path for single-shot invert-and-transform.
Expose only the computing of the explicit inverse matrix in the API.
However, the matrix inversion tests need access to the internal
functions. Designate a unit test build by #defining UNIT_TEST, and
export the internal functions in that case.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Add a new directory tests/ for unit test applications. This directory
will be built only if --enable-tests is given to ./configure.
Add matrix-test application. It excercises especially the
weston_matrix_invert() and weston_matrix_inverse_transform() functions.
It has one test for correctness and precision, and other tests for
measuring the speed of various matrix operations.
For the record, the correctness test prints:
a random matrix:
1.112418e-02 2.628150e+00 8.205844e+02 -1.147526e-04
4.943677e-04 -1.117819e-04 -9.158849e-06 3.678122e-02
7.915063e-03 -3.093254e-04 -4.376583e+02 3.424706e-02
-2.504038e+02 2.481788e+03 -7.545445e+01 1.752909e-03
The matrix multiplied by its inverse, error:
0.000000e+00 -0.000000e+00 -0.000000e+00 -0.000000e+00
0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00
-0.000000e+00 -0.000000e+00 0.000000e+00 -0.000000e+00
0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00
max abs error: 0, original determinant 11595.2
Running a test loop for 10 seconds...
test fail, det: -0.00464805, error sup: inf
test fail, det: -0.0424053, error sup: 1.30787e-06
test fail, det: 5.15191, error sup: 1.15956e-06
tests: 6791767 ok, 1 not invertible but ok, 3 failed.
Total: 6791771 iterations.
These results are expected with the current precision thresholds in
src/matrix.c and tests/matrix-test.c. The random number generator is
seeded with a constant, so the random numbers should be the same on
every run. Machine speed and scheduling affect how many iterations are
run.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Ander Conselvan de Oliveira
Daniel Stone
Kristian Høgsberg
Casey Dahlin
Tiago Vignatti
Pekka Paalanen