The Makefile.win32 build system assumes that the files are in the same
directory level. If this is not the case, the compiler fails when it
tries to write the object files to a non-existing directory.
This can be fixed simply by making sure that the destination directory
always exists.
Fixes:
fatal error C1083: Cannot open compiler generated file:
'release/win32/cairo-win32-debug.obj': No such file or directory
I suspect I may split the win32 code into a few more files, so move it
to its own directory to reduce the clutter.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is initially based around the requirements for handling internal
fallbacks to the image compositor and reducing the number of pixels
required to be transferred.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The pattern creation function call in the example code has one _mesh too
much. This hopefully fixes the mesh mismatch mess :)
Signed-off-by: Nis Martensen <nis.martensen@web.de>
Signed-off-by: Uli Schlachter <psychon@znc.in>
Update to latest surface backend structure, removed obsolete functions
and fixed functions API in order to be compatible with backend definition.
Fixed compilation with Qt5
GCC complains that:
cairo-surface-observer.c:289:26: warning: ignoring return value of
'cairo_device_acquire', declared with attribute warn_unused_result
[-Wunused-result]
Explain why it's safe to ignore it in a comment.
Making cairo_surface_observer_print() and
cairo_device_observer_print() return the status of the observer or of
the stream makes it possible to correctly track what kind of error
happens if the print is not successful.
This makes the functions more consistent with existing API with a
similar signature like cairo_surface_write_to_png_stream().
If a bounded recording surface doesn't have its extents .x and .y at the
surface's origin, this code was translating all clips to make up for that.
However, the clip already is in device space.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41583
Signed-off-by: Uli Schlachter <psychon@znc.in>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Rather than the operation extents which may be larger. It would be
beneficial to trim to the intersection instead and tweak the pattern
matrices - however this is the fallback path and so hopefully less
frequently trod!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When checking for continuations on the right-hand edge, the actual
direction of the edge is immaterial as it is sorted into ascending
y-order and the direction is fixed up when emitting into the output
polygon.
Fixes assertion introduced with 658fa75a5c.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Only bail if we need to combine clipping with the spans (either for a
bounded or unbounded operation).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we steal the boxes, we leave behind an extents-only clip, i.e. only
without a path or boxes, in which case do not return FALSE for the
is-contained check on a rectangle.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
By simply swapping the continuation edges, we end up with a set of edges
that are defined over a shorter range than their extents. Whilst this is
numerically stable at our normal precision we start to encounter issues
when using a coarser grid during rasterisation as the derivative of the
edge becomes unstable.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44722
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Rewrite the directfb backend as nothing more than a simpler image
compositor onto a shadowfb that is flushed back to the dfb surface as
required. Future refinements would be to add damage tracking, and to mix
the useful directfb operations (such as solid fills and alpha blends).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Replace the assertion that the context is flushed when we destroy the
operation and jfdi. Easiest way to resolve it rather than untangle just
why we end up there with an unflushed context.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When painting a GL surface pattern from one context to a
a surface of another context, be careful to manage the
multiple contexts so that they do not stomp on each other.
[ickle: Preserve fast path for GL subsurfaces]
Printing to a printer with an Adobe PostScript 3 interpreter fails
with rangecheck when the shading domain is not [ 0 1 ]. Workaround
this by using a type 3 function to map from [ 0 1] to the required
domain.
For a foreign drawable, we have to assume to that is dirty upon creation
or otherwise we fail to read back the correct pixel data when copying to
an image.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we need to fallback and perform a copy first to a pixmap for a
partially unviewable Window, we need to copy its inferiors as well.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
cairo-xlib semantics state that we copy the contents of a Window's
children when we use a Window as a source in a cairo operation. This
requires that we set the IncludeInferiors SubwindowMode on the GC.
However, we can only set one SubwindowMode for an operation and our
semantics are that drawing performed by cairo onto a Window are clipped
by its children (the ClipByChildren SubwindowMode). Therefore if we have
to copy between two Window, we can not use CopyArea. Furthermore, we
cannot tell if an external Drawable is a Window or a Pixmap, therefore
we treat all foriegn Drawables as Window.
Failure here means falling back to a render path, where we can
independently control the subwindow mode on the source and destination,
or to a GetImage/PutImage if the xserver does not support render.
Reported-by: Benjamin Otte <otte@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The only reliable method would be to query the xserver for the
matching bpp for a particular depth. In the absence of such information,
simply chose the next higher power-of-two(depth).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Both MSVC and Sun Studio Compiler complain about void values being
returned.
Fixes:
cairo-raster-source-pattern.c(93) : warning C4098:
'_cairo_raster_source_pattern_release' : 'void' function returning a
value
CAIRO_ANTIALIAS_{FAST,GOOD,BEST} were introduced and used in
cairo-quartz-font.c by commit 70cd3b473d.
Fixes the warnings:
cairo-quartz-surface.c: In function '_cairo_quartz_cg_glyphs':
cairo-quartz-surface.c:1976: warning: enumeration value 'CAIRO_ANTIALIAS_FAST' not handled in switch
cairo-quartz-surface.c:1976: warning: enumeration value 'CAIRO_ANTIALIAS_GOOD' not handled in switch
cairo-quartz-surface.c:1976: warning: enumeration value 'CAIRO_ANTIALIAS_BEST' not handled in switch
