Round off fractions from non-transformed surface position coordinates.
Transformed surface moved by a client may have non-integer position
coordinates. That is required to prevent drifting on continuous
resizing.
We can round the position to integers when the surface is not (anymore)
transformed.
This change may fix a rounding inconsistency in the opaque region setup,
where the rectangle is initialised from the coordinates without explicit
rounding operation.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
In the past, weston_surface_configure() was used to change the geometry,
apply damage, and assign an output.
Remove all calls to weston_surface_configure() that do not change the
surface geometry. Add damage calls where needed to keep the wanted
configure side-effects.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Move the call to assign an output from weston_surface_configure() to
weston_surface_update_transform().
As update_transform takes new geometry into use, it should also reassign
the output for the surface, but only if an output was already assigned.
Add explicit assing output calls to where we relied on
weston_surface_configure() unconditionally assigning the output.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Move the surface opaque region setup from weston_surface_configure() to
weston_surface_update_transform(), so we have less reason to call
update_transform from configure. Opaque region depends on geometry,
after all.
Also move the opaque field from weston_surface to
weston_surface::transform to make this obvious.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Remove redundant weston_surface_update_transform() calls from within
output repaint paths, and add a comment that we need to rely on
surface->geometry.dirty == 0 within the repaint sub-functions.
Now that weston_surface_update_transform() does damage as needed, and
weston_output_repaint() explicitly calls update_transform, we can reduce
the updates in rotate_grab_motion() to simply scheduling a repaint. This
will guarantee that the change in rotation ends up on screen ASAP.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
weston_surface_update_transform() is similar to
weston_surface_configure() in that it changes the surface region on
screen. Unlike configure, update_transform forgets to deal damage at
all, yet it is the only place where we can do damage_below() as needed.
Add a damage_below call to deal damage for the old surface region only
when needed. This uses the cached state from surface->transform to get
the old region.
Add a damage call to deal damage for the new surface region, after
updating the cached state.
Add a repaint call, since we have changed the scene and should render it
out.
This change fixes the rotation not updating the screen properly.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
The non-transformed case looked a little odd, calling
weston_surface_to_global(), since it already tests for transform.enabled
and simply uses width, height for the box.
Streamline it, by open-coding weston_surface_to_global(), and avoiding
another call into weston_surface_update_transform(). This way it does
not look suspicious to me.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
In surface_compute_bbox(), call surface_to_global_float() instead of
weston_surface_to_global(). This avoids the recursion:
weston_surface_update_transform()
weston_surface_update_transform_enable()
surface_compute_bbox()
weston_surface_to_global()
weston_surface_update_transform()
which might be non-obvious when reading the code.
Computing the min and max coordinates in floats, we can have a tight
rounding margin by using floor() and ceil().
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Split two helper functions out of weston_surface_update_transform() to:
- make the code clearer
- update the bounding box properly even if transformation fails
- unify the return point
Also add a comment on what matrix.d[12] is.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Extract the core into a function that does not call
weston_surface_update_transform() or schedule repaint.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Rotating a surface should not force a full display repaint, so remove
that.
This change exposes a bug: weston_surface_update_transform() does not
apply damage, but it does change surface geometry. While you rotate a
surface, repaints do not work.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Add widget_set_size in the initiate time to allow smoke get the
correct surface later. Or it will report segment fault error because
of the null surface.
Also add resize_handler to not allow resizing just like flower.
Signed-off-by: Juan Zhao <juan.j.zhao@linux.intel.com>
Transform a menu popup the same as its parent surface.
The parent's transformation is snapshotted at the popup map() time, and
does not follow further parent motion.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Computing the real maximal opaque screen aligned rectangle of a
transformed surface is hard. Let's drop the opaque optimisation
instead.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
When a transformed (rotated) surface is continuously resized from its
top-left corner, its location will drift. This is due to accumulating
rounding errors in transforming an offset from surface-local to global
coordinates in surface_attach().
Diminish the drift down to unobservable level by changing the
weston_surface global position from integer to float.
The offset transformation is now done without rounding. To preserve the
precision, wl_shell::configure() interface must use floats, and so does
weston_surface_configure(), too.
The con of this patch is that it adds inconsistency to the surface
position coordinates: sometimes they are floats, sometimes integers.
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>
http://lists.freedesktop.org/archives/wayland-devel/2012-January/001975.html
reports a linking problem:
/usr/bin/ld: libtoytoolkit.a(cairo-util.o): undefined reference to
symbol 'png_set_filler@@PNG12_0'
/usr/bin/ld: note: 'png_set_filler@@PNG12_0' is defined in DSO
/usr/lib/i386-linux-gnu/libpng12.so.0 so try adding it to the linker command line
/usr/lib/i386-linux-gnu/libpng12.so.0: could not read symbols: Invalid
operation
collect2: ld returned 1 exit status
make[3]: [weston-terminal] Error 1 (ignored)
A similar problem is diagnosed here:
http://lists.fedoraproject.org/pipermail/devel/2010-March/133601.html
As some distros are shipping linkers, that do not resolve symbols from
implicitly linked libraries, check and link libpng explicitly.
Cc: nerdopolis <bluescreen_avenger@verizon.net>
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Do not build toytoolkit applications that use GL, if Cairo-egl is not
available. These applications (which happen to be also the full GL
clients) do not work at all without Cairo-egl, and fail at runtime with
"unable to acquire window surface".
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>
Pekka Paalanen
Eric Anholt
Kristian Høgsberg
Juan Zhao
Peter Hutterer
Jesse Barnes