default-context: Convert the relative path segments into the backend coordinates

When transforming the incoming paths, the goal is to transform them from
user space onto the target coordinate system. Currently for relative
paths we used user_to_device_distance as we presumed that there was no
backend scale factor. However, Alex Larsson noticed that these then
broke when playing around with such a device transform...

Reported-by: Alexander Larsson <alexl@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
path: Update last_move_point after move-to

Reported-and-tested-by: Jussi Kukkonen <jku@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54549
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
image: Check for an error surface before dereferencing the backend

As the surface->backend will be NULL in such an error surface, and we
may be legitimately doing boundary checks to reject the error surface.
The alternative would be to set an explicit error surface backend.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54664
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
xlib/shm: Explicitly release shm surface if we do not own the pixmap

In this case we want to prevent the short-circuiting of the flush of the
ShmPixmap that is ordinarily performed during finish().

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
context: Add missing functions to transform between user and backend coordinates

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
path: Convert from backend coordinates back into user coordinates

Fixes regression from commit 83bfd85a1378e61b8bdc3f554f5e07900311f61f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Apr 23 19:45:26 2010 +0100

    Implement cairo_backend_t

As there exists no public API to perform the operation we needed, and we
failed to create one, the constructed path failed to correctly remove
the device offset.

Fixes copy-path under device translation.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54732
Reported-by: Benjamin Berg <benjamin@sipsolutions.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
test: Add degenerate closed path case to get-path-extents

This is a testcase to ensure that we do not regress
https://bugs.freedesktop.org/show_bug.cgi?id=54549 (which is already
fixed by b0c466e27afcec230b2c9436eeb924c05123a544).
xcb: Always flush the fallback damage to foreign drawables

We need to flush any fallback to a foreign drawable upon finish.
However, we must be careful not to attach the snapshot in that case or
else we end up with an expected reference. This is similar to the
treatment of xlib/shm in commit f864e2d70.

Reported-by: Henry Song <henry.song@samsung.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
xlib: Fix regression in cairo_xlib_surface_set_drawable()

In commit 0bfd2acd35547fc2bd0de99cc67d153f0170697d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Aug 13 01:34:12 2012 +0100

    xlib: Implement SHM fallbacks and fast upload paths

I made the mistake of inverting the logic for
cairo_xlib_surface_set_drawable() causing it then to never update.

Thanks to Uli Schlachter for spotting my error.

References: https://bugs.freedesktop.org/show_bug.cgi?id=54657
Reported-by: Weng Xuetian <wengxt@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
xlib: Explicitly discard the fallback shm pixmap upon user modification

If the user changes the size of the underlying drawable, we much make
sure that we discard the current ShmPixmap in order to create a new
fallback pixmap of the correct size next time.

Reported-by: Weng Xuetian <wengxt@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
xlib: Force the fallback flush before updating the external Drawable

_cairo_surface_begin_modification() performs an internal flush, for
which the xlib backend skips flushing the fallback surface as it will
continue to use it for the subsequent operation. In the case where we
are flushing prior to updating the Drawable, we need to perform an
external flush which will trigger the posting of the damage from the
fallback surface.

Reported-by: Weng Xuetian <wengxt@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=54657
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
xlib: Do not call _cairo_xlib_surface_flush directly

Use the higher level layer to be sure we detach any snapshots and other
cached data that is invalidated along with the change of Drawable.

Pointed out by the eternally wise Uli Schlachter.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
xlib: Destroy the fallback damage along with the fallback surface

Whenever we discard the fallback surface, we need to destroy the
associated damage tracking, so move this into the common discard
routine.

This should fix the issue when trying to flush the fallback before
the user modifies any foreign Drawables. The current code issued the
flush and then explicitly discard the fallback, but unless it was idle
at the time of the flush the associated damage would not have also been
destroyed. Asserts followed.

References: https://bugs.freedesktop.org/show_bug.cgi?id=54657
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
xlib: Reset fallback counter when discarding the fallback

References: https://bugs.freedesktop.org/show_bug.cgi?id=54657
gl: Do less work when acquiring and releasing devices

After acquiring a GL device and the same GL context, surface, and
display combination is already active outside of Cairo, do not ask EGL
or GLX to change the current context as that may cause a flush on some
drivers. Also do not unset the context when releasing the device for the
same reason.