csi-trace does not show help string correctly, due to a bug in its
command line argument parsing. strcmp returns 0 when there is an exact
match, which means it requires an inverted test.
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
I already did the same thing in commit 3e22a8580a. That commit added
a GENERATE_REFERENCE mode that does not use threads and used that for
generating the reference image.
However, the above commit falls into the range between commits
fb57ea13e0 and 3d94269bd4. The later commit reverts the earlier one,
which changed the way that image downscaling works / is used.
This means that the reference image that were generated back then were
broken. Thus, regenerating the images is the right thing to do.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Acked-by: Bryce Harrington <bryce@osg.samsung.com>
There is a global pixman_glyph_cache_t instance that is initialized on
first use and shows up in valgrind output as a relatively large leak (I
think it was about 200 KiB). The reason for this is that this cache is
not freed by cairo_debug_reset_static_data().
This commit wires up freeing the cache to
cairo_debug_reset_static_data().
This cache was introduced in commit 615205cf07 from 2012.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Valgrind reports that xlib-render-compositor's composite_traps()
accesses uninitialized memory when traps->num_traps == 0.
This happens in the line that says
if (xtraps[0].left.p1.y < xtraps[0].left.p2.y) {
after the 'for' loop. We can actually return early if there are no
trapezoids to render.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=91271
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Under Win32, when you have a multiple-monitor setup, Windows creates a
'virtual desktop', which is a rectangle surface that extends across all
monitors.
The primary monitor always starts with the top-left corner at coordinate
(0,0). If you have any other monitors which extend to the left or
above the primary monitor, the virtual desktop's top-left corner will
actually have coordinates which are negative.
This creates an issue in Cairo with the desktop DC, i.e. when you use a
DC from the function GetDC(NULL). The same thing can occur with other
third party libraries like GTK, when you access the Cairo surface from
the root window.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=100793
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
cairo-ft-font.c: In function ‘_cairo_ft_has_color_glyphs’:
cairo-ft-font.c:3011:9: warning: ignoring return value of ‘_cairo_ft_unscaled_font_lock_face’, declared with attribute warn_unused_result [-Wunused-result]
_cairo_ft_unscaled_font_lock_face (unscaled);
^
cairo-misc.c:806:43: warning: passing argument 1 of ‘_cairo_atomic_ptr_get’ from incompatible pointer type
C = (locale_t) _cairo_atomic_ptr_get (&C_locale);
^
cairo-misc.c:811:45: warning: passing argument 1 of ‘_cairo_atomic_ptr_cmpxchg_impl’ from incompatible pointer type
if (!_cairo_atomic_ptr_cmpxchg (&C_locale, NULL, C)) {
^
Routines are expecting a void** so cast.
According to "man setjmp", one possible way to avoid variable clobbering
is to declare them as volatile. Thus, this commit turns the variables
that are changed between setjmp() and longjmp() and whose values are
still needed after setjmp() returned the second time into volatile
variables.
The warning in cairo-bentley-ottmann-rectangular.c is worked around by
not initializing the variable before setjmp(). To be honest, I don't
understand why the compiler warns here at all since the value of update
is clearly not used after setjmp()'s second return.
This commit re-fixes the warnings that were reintroduced in commit
82f40285 which reverted b092b63.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Acked-by: Bryce Harrington <bryce@osg.samsung.com>
The cairo_font_options_t struct may now contain allocated
memory, so call fini whenever we are about to let go of an
embedded cairo_font_options_t struct.
The variations member of cairo_font_options_t is allocated,
so we need to have a method to free it for cases where
the struct is embedded in larger structs, such as cairo_ft_options_t.
This reverts commit b092b63119 which
introduced a wrapper function around setjmp(). To quote from man setjmp:
If the function which called setjmp() returns before longjmp() is
called, the behavior is undefined. Some kind of subtle or unsubtle
chaos is sure to result.
Since after the above commit setjmp() is called from the wrapper
function, the result might or might not work, depending on compiler
settings. If the setjmp() wrapper is not inlined, then the state of the
stack after longjmp() will likely be garbage.
We currently (have to) apply font variations for every glyph.
Calling FT_Set_Var_Design_Coordinates has expensive side-effects,
like resetting the autohinter, so we should avoid doing it
fht he coordinates don't actually change.
So far, we only call cairo_ft_apply_variations() in
cairo_ft_scaled_font_lock_face(), but this function is not
used internally. We need to apply it also when loading
glyphs.
This makes pango-view show font variations correctly.
Save the original face_index also for the from_face case,
so we can always rely on it when applying font variations.
This prevents us from running into the same trap we've seen
before where ft_face->face_index changes underneath us as
font variations are applied.
We must not look at the instance_id field of the cached ft_face,
since freetype changes it underneath us (if we set the axis values
to match a named instance, the instance_id gets changed to reflect
that). Thankfully, we have the original instance_id stashed away
in the cairo_unscaled_font, so we can just use that to decide if
we are dealing with a named instance or not.
This makes the font variations tests pass.
This test checks that passing font variation settings via
font options has the desired effect. It checks this by reading
the effective axis values out of the FT_Face after creating
a font with these options.
