Building cairo without font-config fails because test/font-variations.c
was getting compiled without freetype2.
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
This finishes a patch series to speed up CAIRO_OPERATOR_SOURCE when used
to copy data to a argb32 cairo surface corresponding to a win32 dc from
a "backbuffer" - DibSection-based cairo surface created with
cairo_surface_create_similar().
This final patch allows the GDI compositor to be used on argb32
surfaces. For display surfaces, only copying is allowed with gdi (by
BitBlt), since other operations are filtered by flags in
implementations.
But since copying pixels is the only operation used in the most common
scenario (prepare an offscreen image and send it to the screen) - this
is important for presenting argb32 windows with Cairo directly or with
gtk+gdk (which nowadays always creates argb32 windows).
Before this patch pixel copy worked by:
1. mapping image to memory (by copying data from window dc to system
memory which is very slow on windows maybe due to gpu or interprocess
access)
2. copying new data over that image.
3. copying updated image from system memory back to window dc.
After this patch there is only one step:
2+3. Copying new data over window dc.
Completely eliminating step 1 gives a very huge speedup and allows
argb32 cairo drawing be as fast as typical dibsection-buffered gdi
drawing.
There is quick & dirty cairo-vs-gdi perf test made for this patch set:
https://gitlab.gnome.org/galkinvv/cairo/snippets/109
See the Cairo mailing list for April 2018 for data and discussion of
performance improvements.
End-user visible speedup does present too - it relates to the following bug
https://gitlab.gnome.org/GNOME/meld/issues/133
This Cairo speedup allows more simultaneous meld windows
without eating 100% of cpu core time on spinner rendering.
This belongs to a patch series that speeds up CAIRO_OPERATOR_SOURCE when
used to copy data to an argb32 cairo surface corresponding to a win32 dc
from a "backbuffer" - DibSection-based cairo surface created with
cairo_surface_create_similar().
This patch introduces checks to ensure that no solid brush GDI operations
are attempted when using argb32 surfaces. Doing this allows enabling
usage of the GDI compositor when these surfaces are in use.
To make these checks work, _cairo_win32_flags_for_dc disables
STRETCHBLT, STRETCHDIB and RGB_BRUSH in the argb32 flag.
_cairo_win32_flags_for_dc() is also refactored to make the distinction
between rgb24 and argb32 more readable. All logic & flags for rgb24
surfaces are retained, except for the addition of
CAIRO_WIN32_SURFACE_CAN_RGB_BRUSH.
The logic of forbidding AlphaBlend on display surfaces is also
kept as is without investigation.
This is part of a patch series to speed up CAIRO_OPERATOR_SOURCE when
used to copy data to an argb32 cairo surface corresponding to a win32 dc
from a "backbuffer" - DibSection-based cairo surface created with
cairo_surface_create_similar().
This initial patch presents only private header changes without changing
any implementation logic.
The big problem with argb32 surfaces and GDI is that GDI is unable to
correctly set the alpha channel when using operations other than BitBlt
and AlphaBlend.
To solve this, a CAIRO_WIN32_SURFACE_CAN_RGB_BRUSH flag is introduced in
this commit to be mark surfaces that correctly handle such brushes
- essentially all surface types except argb32.
The _cairo_win32_flags_for_dc() call receives a new argument that is
used to calculate the flag.
_cairo_malloc(0) always returns NULL, but has not been used
consistently. This patch replaces many calls to malloc() with
_cairo_malloc().
Fixes: fdo# 101547
CVE: CVE-2017-9814 Heap buffer overflow at cairo-truetype-subset.c:1299
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Fonts are kept in a hash table, so when creating a new font, the code
first checks the hash table for an already-existing entry and only then
is a new instance really created. There is an assert that checks that
the key used for the hash table lookup is the same as the instance that
is created later has, because otherwise the hash table was checked
incorrectly.
This assert failed in some conditions.
Fix this by fixing some places that initialised ft hash keys in a wrong
way.
Patch by Behdad Esfahbod and submitted via bugzilla.
Source: https://bugs.freedesktop.org/show_bug.cgi?id=105746#c4
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=105746
Signed-off-by: Uli Schlachter <psychon@znc.in>
FT_HAS_COLOR() macro is unavailable in older freetype2 without the color
font feature.
Compile and link a source including FT_HAS_COLOR(); if it fails (which
can happen on older FreeType2) then define FT_HAS_COLOR(x) as (0).
Patch from suzuki toshiya <mpsuzuki@hiroshima-u.ac.jp>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Implement suggestion by Adrian Johnson to comment out skia in
configure.ac to avoid presenting it as an option to users. This was
discussed on the Cairo mailing list in September 2017.
Skia is not API stable and is not available in packaged+versioned forms,
resulting in it being a continually moving target. I.e. it's pretty
much always unusably out of date. The last update to the skia backend
was in 2014, and had not been updated very regularly prior to that.
We'll simply disable it for now. If no one complains by the next Cairo
snapshot release, we'll assume no one is needing it and will drop the
code entirely.
Meanwhile, if anyone does need it, it can be uncommented and used.
(The changes to the win32 build config appear to be automatically
generated as a result of disabling the feature in configure. I'm
committing them to avoid confusion.)
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.
