When cairo_surface_create_for_rectangle() is given non-integer parameters,
the subsurface's size may be negative(e.g x = 0.2, width = 0.7, the
final width will be -1). This illegal surface may cause crash somewhere
upon later use, and although the fractional subsurface is ill-defined,
we should never crash!
I need to remember that the translation for the pattern matrix is the
inverse of the translation for drawing.
Fixes: subsurface-modify-parent
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Only allow one owner to keep their snapshot on the subsurface, and
so automatically replace any previous snapshot.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Following the previous commit, we only allocate a simple image when
acquiring the source so we only need to unreference it upon release.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Remove all of the special casing and simply extract the source. The time
for special casing is to avoid calling the generic acquire in the first
place, so kiss.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Having spent the last dev cycle looking at how we could specialize the
compositors for various backends, we once again look for the
commonalities in order to reduce the duplication. In part this is
motivated by the idea that spans is a good interface for both the
existent GL backend and pixman, and so they deserve a dedicated
compositor. xcb/xlib target an identical rendering system and so they
should be using the same compositor, and it should be possible to run
that same compositor locally against pixman to generate reference tests.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
P.S. This brings massive upheaval (read breakage) I've tried delaying in
order to fix as many things as possible but now this one patch does far,
far, far too much. Apologies in advance for breaking your favourite
backend, but trust me in that the end result will be much better. :)
Ouch, a nasty bug surfaces after rearranging code to fix the others.
Another self-copy loop this time through a subsurface of a recording
surface.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
And not the backend directly as this bypasses the extra steps taken in
the higher level to do common actions such as detach snapshots.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A common requirement is the fast upload of pixel data. In order to
allocate the most appropriate image buffer, we need knowledge of the
destination. The most obvious example is that we could use a
shared-memory region for the image to avoid the transfer cost of
uploading the pixels to the X server. Similarly, gl, win32, quartz...
The other side of the equation is that for manual modification of a
remote surface, it would be more efficient if we can create a similar
image to reduce the transfer costs. This strategy is already followed
for the destination fallbacks and this merely exposes the same
capability for the application fallbacks.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Adrian Johnson found that I had broken show_page() and pinpointed the
cause to being that cairo_show_page() was being called on the recording
surface and not the pagination surface after my overhaul for
cairo_backend_t. In fact, the problem was far more severe as the mistake
caused the created context to point to the wrong surface entirely,
bypassing the surface proxy.
What is desired is for the proxy's target surface to choose what manner
of context is should use, but for all calls into the surface backend to
go through the proxy surface.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Step 1, fix the failings sighted recently by tracking clip-boxes as an
explicit property of the clipping and of composition.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Allow a backend to completely reimplement the Cairo API as it wants. The
goal is to pass operations to the native backends such as Quartz,
Direct2D, Qt, Skia, OpenVG with no overhead. And to permit complete
logging contexts, and whatever else the imagination holds. Perhaps to
experiment with double-paths?
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The code is passing in the extra info received from
the target surface's acquire_source() method to
_cairo_surface_get_extents() rather than the acquired
source surface itself.
Whenever subsurface extents are not contained in the target extents,
using the source image given by the target (with origin corrected by
using an appropriate offset in the data pointer) is not a valid
operation. Fallback to cloning in that case.
Do not try to hide being a subsurface.
This would cause confusion when users where calling surface-type
specific getters on subsurfaces.
FIXME: We still need public API to access a subsurface's target though.
Carefully handle subsurfaces of a recording surface through the analysis
and paginated surfaces so that we can generate a native pattern for the
vector backends, demonstrated by the PostScript backend.
Nothing remarkable, just a lot of bookkeeping to track the wrapped
surface types and to apply the correct offsets when generating the
subsurface pattern.
After a renewed discussion, it was pointed out that the API in Cairo was
not restrictive and by using doubles we would be consisted with the rest
of the API. Thus prompting the name change to
cairo_surface_create_for_rectangle()
similar to cairo_rectangle().
And document the public API.
I updated the Free Software Foundation address using the following script.
for i in $(git grep Temple | cut -d: -f1 )
do
sed -e 's/59 Temple Place[, -]* Suite 330, Boston, MA *02111-1307[, ]* USA/51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA/' -i "$i"
done
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=21356
The return is just a hint that the clip is empty, however we are about
to immediately apply the surface clip and so do not care for an
'optimised' path.
Force the subsurface extents to be inside the target extents and
compose subsubsurfaces offsets correctly.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
The device is a generic method for accessing the underlying interface
with the native graphics subsystem, typically the X connection or
perhaps the GL context. By exposing a cairo_device_t on a surface and
its various methods we enable finer control over interoperability with
external interactions of the device by applications. The use case in
mind is, for example, a multi-threaded gstreamer which needs to serialise
its own direct access to the device along with Cairo's across many
threads.
Secondly, the cairo_device_t is a unifying API for the mismash of
backend specific methods for controlling creation of surfaces with
explicit devices and a convenient hook for debugging and introspection.
The principal components of the API are the memory management of:
cairo_device_reference(),
cairo_device_finish() and
cairo_device_destroy();
along with a pair of routines for serialising interaction:
cairo_device_acquire() and
cairo_device_release()
and a method to flush any outstanding accesses:
cairo_device_flush().
The device for a particular surface may be retrieved using:
cairo_surface_get_device().
The device returned is owned by the surface.
A subsurface is a region of another surface that may be used either to
restrict the writable area of a context or the readable extents of a
source. Whilst writing, access to the exterior of the subsurface is
prevented via clipping and when used as a source reads from the exterior
of the subsurface are governed via the extend mechanism of the pattern.
