The previous approach using foreground colors in user fonts does not
work for gradients since the foreground color is not available at the
time of recording.
Add a new function cairo_user_scaled_font_get_foreground_source() that
can be called by the color render function to retrieve the foreground
pattern. Calling this function signals to cairo that the foreground
color is used. In this case cairo will call the render function
whenever the foreground color has changed.
The problem is _cairo_recording_surface_replay_and_create_regions()
stores the cairo_recording_region_type_t in the same structure as the
recording commands. This does not work well when the recording surface
is used as source by multiple surfaces
Fix this by moving the cairo_recording_region_type_t into a separate
struct cairo_recording_regions_array_t. This struct is stored in a
list that allows multiple create regions results to be store in the
surface.
The new function _cairo_recording_surface_region_array_attach() is
used to create a new cairo_recording_regions_array_t, attach it to the
recording surface and return a unique region id.
The _cairo_recording_surface_replay_and_create_regions() and
_cairo_recording_surface_replay_region() functions use this region id
to identify the cairo_recording_regions_array_t.
To handle nested recording surfaces, when replaying a recording, the
region id is passed to the target as an extra parameter in the surface
pattern. The wrapper surface makes a temporary copy of the pattern to
ensure the snapshot pattern in the recording surface is not modified.
cairo_recording_regions_array_t has a reference count so the target
can hold on to the cairo_recording_regions_array_t after the paginated
surface has called _cairo_recording_surface_region_array_remove().
WINVER and _WIN32_WINNT macros were defined in each source files and
headers that were including <windows.h>. However, because DirectWrite
requires new Windows API, some files included <windows.h> without the
version macros. This inconsistency sometimes caused troubles.
Define the version macros in meson.build.
GeometryRecorder class was calling _controlfp_s with MCW_PC to reset
the floating point precision to default. However, MCW_PC isn't
supported for ARM or x64 platforms. It reports an assertion failure
for them. And, Cairo isn't changing the MCW_PC setting. Removed the
calls. Also, removed `GetFixedX` and `GetFixedY` methods because they
called only `_cairo_fixed_from_double`.
Fixescairo/cairo#566
Checking that public header files #include "cairo.h" first (or none)
Checking that private header files #include "some cairo header" first (or none)
Checking that source files #include "cairoint.h" first (or none)
./win32/cairo-dwrite-font-public.c:#include "cairo-win32-private.h"
Checking that there is no #include <cairo.*.h>
./win32/cairo-dwrite-font-public.c: * #include <cairo-win32.h>
Checking that feature conditionals are used with #if only (not #ifdef)
This adds a missing cairoint.h include and makes
check-preprocessor-syntax.sh slightly better in not warning about
includes in C comments.
Signed-off-by: Uli Schlachter <psychon@znc.in>
SVG fonts are returning DWRITE_GLYPH_IMAGE_FORMATS_NONE as well
as DWRITE_GLYPH_IMAGE_FORMATS_SVG in GetCurrentRun() resulting in the
outline glyph and color glyph both rendered to the same glyph image.
There may be different versions of fonts with the same name. As an
additional check, compare the 'head' table wich contains the checksum
for the font.
Also, load the DWrite tables directly to avoid the memcpy in
load_truetype_table.
If the default font is not found, return CAIRO_INT_STATUS_UNSUPPORTED
to cause _cairo_toy_font_face_create_impl_face to create the Twin user
font fallback.
The FT change is because my MinGW build is using a more recent version
of FT.
Remove the disabled _cairo_win32_scaled_font_text_to_glyphs() code to
fix the defined but not used warning.
_cairo_win32_scaled_font_text_to_glyphs() was diabled in d9408041aa with
the comment:
"Currently disable the win32-font text_to_glyphs(), until that one
is updated. Or better yet, remove it and implement
ucs4_to_index(). It's the toy font API afterall."
_cairo_win32_scaled_font_ucs4_to_index() was added in d1c619bc7d.
COLR fonts can have a layer with the same color as the current text
color. This change passes the current color (if solid) through to
the font backend where it can be used to render color fonts.
scaled_glyph_lookup checks if the foreground color has changed (for
glyph that require it) and requests a new color surface if required.
This also fixes a bug where scaled_glyph_lookup would always request a
color surface for glyphs for glyphs in color fonts that do not have
color.
On 64-bit windows, long is 32-bit. When compiling there are a large
number of warnings about mismatched sizes when casting long to/from a
pointer.
Use the (u)intptr_t type for any integer that will have a pointer stored
in it. Use a (u)intptr_t cast when integers are stored in pointers to
silence warnings.
Fixes#263
Surfaces from _cairo_surface_create_in_error() have no backend. This
commit fixes a NULL pointer dereference in cairo_win32_surface_get_dc().
Fixes: https://gitlab.freedesktop.org/cairo/cairo/-/issues/405
Signed-off-by: Uli Schlachter <psychon@znc.in>
Found via `codespell -i 3 -w -I ../cairo-word-whitelist.txt -L tim,ned,uint`
Follow up of 12cb59be7d
Reviewed-by: Bryce Harrington <bryce@bryceharrington.org>
Converting a series of glyphs to a path triggers an out of memory error
if there is a space glyph (bytesGlyph==0). The regression was
introduced by commit 19982393 in cairo-win32-font.c:107.
The behavior of malloc(0) is not well defined - it can return NULL on
some platforms, or an arbitrary (non-allocated) pointer on other
platforms. Commit 19982393 introduced sanity by enforcing that NULL is
always returned in this situation, which inappropriately triggers the
OOM check in _cairo_win32_scaled_font_init_glyph_path(). Instead,
special case the handling for bytesGlyph==0.
Patch authored by Uli Schlachter, based on fix proposed by lb90.
Fixes: https://gitlab.freedesktop.org/cairo/cairo/issues/339
Reference: https://gitlab.gnome.org/GNOME/pango/issues/323
Reviewed-by: Bryce Harrington <bryce@bryceharrington.org>
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>
