This patch has been generated by the following Coccinelle semantic patch:
// Remove useless checks for NULL before freeing
//
// free (NULL) is a no-op, so there is no need to avoid it
@@
expression E;
@@
+ free (E);
+ E = NULL;
- if (unlikely (E != NULL)) {
- free(E);
(
- E = NULL;
|
- E = 0;
)
...
- }
@@
expression E;
@@
+ free (E);
- if (unlikely (E != NULL)) {
- free (E);
- }
Currently we only emit the format, but if you want to later convert
the images to a normal surface for replay it is handy to have the
content.
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>
During replay we want to handle recording surfaces specially, and not
redirect the creation of those to the target surface. This is similar to
the need to keep image surfaces as images during replay.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
cairo-xcb's acquire_source_image implementation will attach the image it returns
as a snapshot to the xcb surface. cairo_surface_mark_dirty_rectangle asserts
that the surface doesn't have any snapshots attached. cairo-trace will emit the
surface to the trace when it was marked dirty by drawing it to an image surface.
The combination of these three things caused a failed assertion when cairo-trace
was used on something which uses xcb/Xlib and which uses mark_dirty.
I found this with firefox and xlib-xcb.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Fixes all warnings that looked like this:
warning: enumeration value 'CAIRO_STATUS_DEVICE_FINISHED' not handled in switch
Signed-off-by: Uli Schlachter <psychon@znc.in>
Restructure the Makefiles in .sources, .am and .win32 to enable
building cairo-script-interpreter on Win32.
Some minor changes are needed to compile on MSVC:
- include stdint.h to define INT_MAX-like macros
- redefine "inline"
- avoid deprecated functions (snprintf, replaced by _snprintf)
- define _USE_MATH_DEFINES so that math.h defines M_PI, M_SQRT2 and
M_LN2
This is a common format used by framebuffers to drive 10bpc displays
and is often hardware accelerated by XRender with underlying support
from pixman's x2r10g10b10 format (which provides coercion paths for
fallbacks).
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
By emitting an empty function name when it it impossible to perform
the lookup, we can get rid of the warning:
trace.c:3714: warning: unused variable ‘symbol’
Additionally, this makes the syntax (or, rather, the parameter count)
for write-to-png-stream the same on every configuration.
Compiler warning saves the day!
trace.c: In function ‘_emit_font_options’:
trace.c:2973:20: warning: comparison between ‘cairo_hint_style_t’ and
‘enum _cairo_hint_metrics’
A genuine bug, thanks gcc!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is consistent with the naming of most cairo types/functions
(example: cairo_foo_surface_*).
The substitution in the code has been performed using:
sed -i 's/cairo_pattern_mesh_/cairo_mesh_pattern_/' <files>
Add the mesh pattern type and an error status to be used to report an
incorrect construction of the pattern.
Update the backends to make them ready to handle the new pattern type,
even if it cannot be created yet.
This should help clarify the documentation by not mentioning non-existent
devices and prevent any assumed coupling between surface-type values and
devices.
Use two levels of pthread support: a minimal level used to
build cairo itself, and a full level to build threaded apps
which want to use cairo. The minimal level tries to use
pthread stubs from libc if possible, but falls back to the
full level if that's not possible. We use CFLAGS=-D_REENTRANT
LIBS=-lpthread to find a real pthread library since that seems
to work on every unix-like test box we can get our hands on.
What we want to use is size_t, but we don't want the implied POSIX
dependency. However, POSIX does say that size_t is an unsigned integer
that is no longer than a long, so it would appear safe to use an
unsigned long as a replacement. Safer at least than unsigned int.
The reuse hit rate is very small, and most images are quickly
distinguished in the first few bytes... Though perhaps not for video as
in the swfdec-youtube case...
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
trace.c:1154: warning: ‘_has_font_face_id’ defined but not used
trace.c:1196: warning: ‘_get_pattern_id’ defined but not used
trace.c:1870: warning: ‘_emit_font_face’ defined but not used
trace.c:1882: warning: ‘_emit_scaled_font’ defined but not used
The script interpreter was reading the length of compressed data as
an host-endian uint32_t, thus making cairo-script able to correctly
read traces that were produced on the same endianness as the one they
ran upon, but unsuitable for portabile cairo-scripts.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Trace files were using host-endian to represent the length of
compressed data, making the trace format not portable.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
When compiling we can depend on whatever version of cairo we need, but
we should be wary of checking for runtime compatibility when building
standalone.
We were exposing the actual value of CAIRO_FORMAT_INVALID
through API functions already, so it makes sense to just
go ahead and put it in the cairo_format_t enum.
Should fix:
Bug 26509 - Cairo fails to compile without mmap
http://bugs.freedesktop.org/show_bug.cgi?id=26509
As reported by Hib Eris, Cairo files to compile under a mingw32
cross-compiler as we use a structure only defined if HAVE_MMAP
unconditionally.
