Support subpixel positioning with a 4x4 subpixel grid.
When compositing glyphs in the image compositor,
we store the subpixel phases in the high bits of the
glyph index. The _cairo_scaled_glyph_index() macro
has been updated to discard these bits. By storing
the phases in the glyph index, the glyph cache just
keeps working. When loading a glyph, the Freetype
font backend shifts the outline according to the
phases.
FT_PIXEL_MODE_BGRA is an enum member, not a define, so it always appears
as 0 in the preprocessor conditions added in commit c0ed8ce1a1.
There is an existing define for color font support, use that instead.
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>
The indentation of this line suggests it is a typo. In any case it
causes the function to unconditionally return immediately, thereby
shortcircuiting it entirely, which does not appear to be the intended
behavior.
Fixes: https://gitlab.com/cairo/cairo/issues/2
Similar to writing png, don't squash 16 bpc to 8 bpc and create
a float surface to contain the image.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Bryce Harrington <bryce@bryceharrington.org>
_cairo_image_surface_coerce will round down the image to a lower
bpp when using one of the floating point formats, so don't coerce those.
This makes the code actually work for those formats.
Because a float takes more storage than u16, we have to convert float
to u16 before calling png_write_image, because png_write
doesn't give us back the original row data, but an in-place copy.
With these changes we can dump floating point files with the highest
possible accuracy, with floats clamped between 0 and 1.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Bryce Harrington <bryce@bryceharrington.org>
IGT wants to add support for planes with a bit depth >10, which
requires a higher precision format than we have currently.
I'm using RGBA as format, because of its existence in OpenGL.
With the new formats we can directly convert our bytes to half float,
or multiply a colro vector with a matrix to go to the Y'CbCr colorspace.
This requires pixman 0.36.0, so bump the version requirement.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
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>
Run the command below suggested by geirha in ##sed@irc.freenode.net.
git grep -l 'http://.*gnome.org' | xargs sed -i 's|http\(://\([[:alnum:].-]*\.\)\{0,1\}gnome\.org\)|https\1|g'
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Run the command below suggested by geirha in ##sed@irc.freenode.net.
git grep -l 'http://.*freedesktop.org' | xargs sed -i 's|http\(://\([[:alnum:].-]*\.\)\{0,1\}freedesktop\.org\)|https\1|g'
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Run the command below suggested by geirha in ##sed@irc.freenode.net.
git grep -l 'http://.*cairographics.org' | xargs sed -i 's|http\(://\([[:alnum:].-]*\.\)\{0,1\}cairographics\.org\)|https\1|g'
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
From further testing and investigation it appears that many PDF viewers
already have a workaround to invert Adobe CMYK JPEGs, so our generated
PDFs display incorrectly with those viewers due to double-inversion.
Further investigation will be needed to find a better solution that
doesn't cause regression for some PDF viewers; perhaps PDF viewers that
lack this inversion workaround should be changed to include it. For now
we'll drop the patch to avoid shipping the regression in 1.16.0.
This reverts commit b207a932a2.
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=97612
Fixes: https://gitlab.freedesktop.org/cairo/cairo/issues/156
num_glyphs and num_clusters are explicitly checked to be non-NULL at the
beginning of this routine, and by this point in the code both have been
deref'd multiple times, so checking them for NULL here again is
superfluous.
It looks like the intent here is to verify the glyphs and clusters
arrays are non-NULL unless their counts are zero, so change the tests
accordingly.
Coverity ID: #983386
Signed-off-by: Bryce Harrington <bryce@bryceharrington.org>
The code is checking a variable is non-NULL after it's already been
dereferenced in an assert.
I'm not certain whether the assert should be conditionalized to only be
tested when right != NULL (which would allow edges_end() to still be
invoked), or if the function should assert right as non-NULL always.
Coverity ID: #1160730
Signed-off-by: Bryce Harrington <bryce@bryceharrington.org>
Reviewed-By: Uli Schlachter <psychon@znc.in>
subrs was already tested for NULL prior to this, and will never be NULL
at this point. Meanwhile, find_token()'s return is unchecked (it can
return NULL and is checked in all other calls). Quite clearly, this is
a copy-paste error from the prior find_token call, and the intent was to
check array_start not subrs.
Coverity ID: #1160662
Signed-off-by: Bryce Harrington <bryce@bryceharrington.org>
Reviewed-By: Uli Schlachter <psychon@znc.in>
Patch 37a22669 improved performance by using bounding box extents.
However, the code appears to be incorrect. If extents is non-NULL it
copies its contents to group->extents, otherwise it sets group->extents
to sensible defaults, but then goes ahead and tries to copy the
undefined contents. This second copy is unnecessary if extents is
non-NULL and will cause a crash if it is NULL.
Drop the extra copy, guessing it's just a typo.
Coverity ID: #1159559
Signed-off-by: Bryce Harrington <bryce@bryceharrington.org>
Reviewed-By: Uli Schlachter <psychon@znc.in>
If the call to _cairo_malloc_ab_plus_c() fails, it returns an error
without first freeing event_y.
Coverity ID: #1160682
Signed-off-by: Bryce Harrington <bryce@bryceharrington.org>
Reviewed-By: Uli Schlachter <psychon@znc.in>
Note this changes the semantics of the value of extra_out such that it
is set to NULL instead of left undefined in case an error is returned.
Coverity ID: 220086
Signed-off-by: Bryce Harrington <bryce@bryceharrington.org>
Reviewed-By: Uli Schlachter <psychon@znc.in>
_cairo_malloc_ab() can return NULL under some circumstances, and all
other callers of this routine in the Cairo codebase check its return, so
do so here as well.
Coverity ID: #1159556
Signed-off-by: Bryce Harrington <bryce@bryceharrington.org>
Reviewed-by: Uli Schlachter <psychon@znc.in>
If the bitmap's min is non-zero, _bitmap_next_id() could break out of
its loop early, before initializing the prev variable. prev would then
be dereferenced without a null ptr check. This condition should never
occur in practice, so add an assert() to assure it doesn't.
Same issue is present in trace.c.
Coverity IDs: #1159557, #1159558
Reviewed-By: Uli Schlachter <psychon@znc.in>
Signed-off-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>
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>
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.)
