Commit a0d6dc4f26 lost one line of code in
the refactoring, and so did not reset the surface damage on repaint
anymore. This causes damage to only accumulate, leading to a full
display redraw every cycle and hiding damage tracking issues.
Put the damage clear back.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
The uniform location variables should be signed, according to the OpenGL
ES 2 specification. Moreover, GL_NONE, i.e. 0, is not an invalid nor
special location; it is actually used as a valid uniform location.
Change struct weston_shader uniform members to signed.
Stop using 0 for identifying a non-existing uniform, use -1 instead.
Furthermore, as the spec says a) glGetUniformLocation() will return -1
for non-active/existing uniforms, and b) glUniform*() function will
simply ignore all calls with location -1, we can simplify the code. We
don't have to avoid locating uniforms that don't exist, and we don't
need to test for them in weston_surface_draw() either.
Remove the micro-optimisation that avoids setting 'alpha' uniform if it
has not changed, in the name of simplification.
Unify shader creation by dropping init_solid_shader(), and calling
weston_shader_init() instead. The downside is that we compile the vertex
shader twice at startup now.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
The x, y offsets in attach request are in surface-local coordinates, as
that is the only coordinate system the clients know about. The offset
must be transformed to global coordinate system to be applied properly.
This approximately fixes the top-left resizing of transformed surfaces.
However, it suffers from drift due to accumulating rounding errors in
continuous resizing.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
This fixes the resize pointer motion vs. surface size mismatch for
right/bottom direction resizes. Top/left resizes need further fixes in
surface motion.
Additionally there is some clean-up in weston_surface_resize() to
eliminate a failure path, and fixing the Weston resize binding's resize
direction heuristic to follow transformations.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
In the stack of transformations, change the rotation to be applied
to the surface before the absolute positioning. Doing so avoids having
to undo and redo the absolute positioning, and we can simply use the
surface center in local coordinates as the origin.
This fixes the surface move. Before, the surface moved along the surface
local axis, but the user expects it to move along the global axis with
the pointer.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Change weston_surface_damage*() functions to use the full surface
bounding box or call surface_compute_bbox() to find the bounding box for
an arbitrary rectangle.
This should fix all rendering artifacts for non-opaque (i.e. ARGB)
transformed surfaces.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Use the bounding box to compute an approximation of which output
contains most of the surface.
Move the region32 init outside the loop, and fini it, too.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
If we ever have transformed cursor surfaces, we would better use the
bounding box to check if it is on the given output.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Use the proper bounding box in clipping the surface repaint area. Fixes
excessive clipping for transformed surfaces.
Also don't leak the region32 on early return.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
weston_surface::transform.boundingbox depends on width and height, and
therefore geometry.dirty flag, so move width and height into geometry.
Fix all users and check that the dirty flag is set.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Compute a surface bounding box, especially for transformed surfaces, for
which one cannot simply use x,y,width,height.
The bounding box depends on width and height, so these are now under the
geometry.dirty flag.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Now that we can insert a transformation before the surface position
translation, we can drop geometry.x,y from the zoom transformation. That
was just undoing and redoing the position translation.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Not sure this check belongs here, but as the position checks are here
too, I added this. Just so we don't forget.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
weston_surface::transform.position depends on x,y, and therefore the
dirty flag, so move x and y into geometry.
Also add the missing dirty flags.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Put the surface translation (absolute position) into the surface
transformations list. This allows to set additional transformations
before and after the global translation.
Having the translation cached, changing the surface x,y now requires to
set the geometry.dirty flag.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Previously, if a surface was transformed, it repainted as a whole,
regardless of the computed repaint region. As damage regions determine
repaint regions and whether a surface is considered for drawing at all,
this lead to disappearing surfaces if all surfaces were considered
transformed. Also transparent transformed surfaces were redrawn without
the surfaces below being properly redrawn, leading to alpha-saturation.
Fix that by making texture_region() use the proper global-to-surface
coordinate transformation for texture coordinates. This makes it
possible to call texture_region() also for transformed surfaces.
As texture coordinates may now lie outside the valid texture image, the
fragment shader is modified to check the fragment texture coordinates.
The special path texture_transformed_surface() is no longer used and is
removed.
This change fixes many of the rendering artifacts related to transformed
surfaces.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
For unifying the coordinate system handling, introduce functions for
converting explicitly between the global and the surface local
coordinate systems.
Use these functions in the input path, replacing
weston_surface_transform().
In the draw path, rewrite transform_vertex() to take in surface local
coordinates.
As shell now uses the new functions, the rotation origin is properly
placed in the middle of the surface.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Add the key binding Super+Alt+MouseLeftButton to start rotating a
surface by dragging. The rotation is removed, when the drag is near the
rotation origin.
Rotated surface are a stress test for input event coordinate
transformations, damage region tracking, draw transformations, and
window move and resize orientation.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
When converting input coordinates from global to surface-local system,
apply the full inverse surface transformation instead of just
translation.
Move weston_surface_update_transform() implementation realier in the
file, no changes.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.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>
Implement 4x4 matrix inversion based on LU-decomposition with partial
pivoting.
Instead of simply computing the inverse matrix explicitly, introduce the
type struct weston_inverse_matrix for storing the LU-decomposition and
the permutation from pivoting. Using doubles, this struct has greater
precision than struct weston_matrix.
If you need only few (less than 5, presumably) multiplications with the
inverse matrix, is it cheaper to use weston_inverse_matrix, and not
compute the inverse matrix explicitly into a weston_matrix.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Remove the inverse matrix member from struct weston_transform. It is
easier (and probably faster, too) to create and store only forward
transformation matrices in a list, multiply them once, and then invert
the final matrix, rather than creating both forward and inverse
matrices, and multiplying both.
Add a stub for the 4x4 matrix inversion function.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Add comments explaining the matrix storage and multiplication, so that
no-one else needs to decipher them again.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Having at most one transformation object attached to a surface is not
enough anymore. If we have a surface that needs to be scaled to
fullscreen, and then we have the zoom animation, we already need two
transformations combined.
Implement support for multiple transformations by adding a transformation
list. The final transformation is the ordered composite of those in the
list. To avoid traversing the list every single time, add a dirty flag,
and cache the final transformation.
The existing transformation users (only zoom) are converted.
Note: surface drawing should honour all kinds of transformations, but
not damage region code nor input event translating code take
transformations into account, AFAICT. Therefore anything but translation
will probably behave badly until they are fixed.
Cc: Juan Zhao <juan.j.zhao@linux.intel.com>
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
This removes more special cases from weston_output_repaint() and we
avoid creating and destroying the surface for each animation frame.
We gain another special case in weston_compositor_top(), but that's
less of a problem, and we'll fix that later.
We've trimmed down the actual repaint loop to just iterating through the
surface list and calling weston_surface_draw(), so we push that to the
backend without too much code duplication.
Pekka Paalanen
Kristian Høgsberg