As noted by Carl during his LCA talk, caching of toy fonts was broken
because we create the scaled font using the implementation font face and
lose the reference to the containing font face that is cached by the toy
font face create routines. So the toy fonts were not being preserved for
the duration of the holdover scaled fonts and we recreated a new font
face, new scaled font and new glyph caches every time we needed a font.
When using MSVC, _cairo_error() can be folded into other identical functions.
If that happens, _cairo_error isn't really useful anymore. Using the
CAIRO_ENSURE_UNIQUE macro makes sure this doesn't happen.
Use __asm to serve as a line delimiter. This allows us to use the
__asm{} block in a macro.
This reverts commit 126824f5e6.
It turns out MSVC doesn't handle line continuation characters in __asm{}
blocks very well, so revert for now until I come up with something that
works.
When using MSVC, _cairo_error() can be folded into other identical functions. If
that happens, _cairo_error isn't really useful anymore. Using the
CAIRO_ENSURE_UNIQUE macro makes sure this doesn't happen.
The _cairo_region_get_boxes() interface was difficult to use and often
caused unnecessary memory allocation. With _cairo_region_get_box() it
is possible to access the boxes of a region without allocating a big
temporary array.
_cairo_win32_tmpfile() uses _open_osfhandle() which is not available
on Windows CE. However, Windows CE doesn't have the permisions problems
that necessitated _cairo_win32_tmpfile() in the first place so we can just
use tmpfile() on Windows CE.
By inlining the operations, and most significantly, precomputing the
combined user-to-backend matrix, we can achieve a speed up of over 50%,
which is a noticeable performance boost in swfdec - where append-to-path
accounts for over 35% [inclusive] of the time for a h/w accelerated
backend.
Move the mime-data into its own array so that it cannot be confused with
user-data and we do not need to hard-code the copy list during
snapshotting. The copy-on-snapshotting code becomes far simpler and will
accommodate all future mime-types.
Keeping mime-data separate from user-data is important due to the
principle of least surprise - the API is different and so it would be
surprising if you queried for user-data and were returned an opaque
mime-data pointer, and vice versa. (Note this should have been prevented
by using interned strings, but conceptually it is cleaner to make the
separation.) Also it aides in trimming the user data arrays which are
linearly searched.
Based on the original patch by Adrian Johnson:
http://cgit.freedesktop.org/~ajohnson/cairo/commit/?h=metadata&id=37e607cc777523ad12a2d214708d79ecbca5b380
Truc Troung reported that the behaviour of
cairo_set_tolerance()/cairo_get_tolerance() was inconsistent with the
documentation, i.e. we failed to mention that the tolerance would be
restricted to the smalled fixed-point value.
Add a sentence to the documentation that describes the restriction without
mentioning what that is... Hopefully that is sufficient detail to
accommodate the reporter, without exposing internal implementation details.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=20095
Bug 20095 - The cairo_set_tolerance() function behavior is inconsistency
with the spec
As pointed out by Truc Truong,
cairo_image_surface_create_from_png_stream() cannot return NULL and so the
documentation was incorrect.
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=20075
Bug 20075 There is a misprint in the spec for
cairo_image_surface_create_from_png_stream() function
This reverts commit 564d64a132.
In hindsight, and with further discussion with Jeff Muizelaar, this
behaviour of using the stored contents from the mime-data is completely
the opposite of the users' expectations. When the user calls
cairo_surface_write_to_png(), usually in the course of debugging their
rendering code, they expect the precise contents of the surface to be
saved.
Since we only need to allocate elts for intersection events and edges, the
number of elts in flight at any one time is actually quite small and can
usually be accommodated from an embedded pool.
Propagate the error status from deep within the bowels, in order to reduce
the number of duplicate _cairo_error() and generally clean up the return
values.
We now have the ability to distinguish an error case where the backend is
left in an inconsistent state from a transitory error. For the former we
need to report the error condition via the return value, which will be
propagated to the font-face. For the latter we just construct an in-error
scaled font nil-object which is passed back to the user.
We only want to set the error state on the backend when it implies that
the font-face is in an inconsistent state. For example, this may be due to
a locking error in the backend or that we have detected a corrupt font.
In contrast, if we merely fail to allocated the scaled font then we just
wish to return that error to the user, without making the font-face itself
inert.
Check the user input for validity before passing the values on to the
backend. Currently the error is detected by the backend and the error is
propagated onto the font-face.
Ensure that the temporary images are freed after we finish with the
pattern.
Note that we are using 3 members of the surface for temporary storage
whilst emitting patterns, this should be reviewed.
_cairo_memory_stream_destroy() finalizes the stream even if the stream was
in error and that error is reported back to the caller - so ensure we
don't try to free the stream again.
Paul Messmer provided a thorough analysis of a race between destroying the
final reference on a font and a concurrent recreation of the font -
demonstrating how it is possible for the create() to return the font that
was in the process of being freed.
To stop the race, we need to recheck the reference count upon taking the
mutex guarding the hash table.
We failed to cleanup the font face correctly after an allocation failure
during _cairo_toy_font_face_init() leading to memleaks and live entries
being left in the font-face hash tables.
As a fun itch to scratch, I've been fixing incorrect uses of the
contraction "it's" in comments within the mozilla source tree (tracked
in https://bugzilla.mozilla.org/show_bug.cgi?id=458167 ), and I ran
across 6 instances of this typo in mozilla's snapshot of cairo.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Adds an error code replacing CAIRO_STATUS_NO_MEMORY in one case where it
is not really appropriate. CAIRO_STATUS_INVALID_SIZE is used by several
backends that do not support image sizes beyond 2^15 pixels on each side.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The agreement on the mailing list was that returning NULL is the right
thing to do, and indeed the callers of _cairo_glitz_surface_create_similar
are prepared to receive NULL and return CAIRO_STATUS_INT_UNSUPPORTED in
that case.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Currently glyphs are cached independently in each font i.e. each font
maintains a cache of up to 256 glyphs, and there can be as many scaled fonts
in use as the application needs and references (we maintain a holdover
cache of 512 scaled fonts as well).
Alternatively, as in this patch, we can maintain a global pool of glyphs
split between all open fonts. This allows a heavily used individual font
to cache more glyphs than we could allow if we used per-font glyph caches,
but at the same time maintains fairness across all fonts (by using random
replacement) and provides a cap on the maximum number of global glyphs.
The glyphs are allocated in pages, which are cached in the global pool.
Using pages means we can exploit spatial locality within the font
(nearby indices are typically used in clusters) to reduce frequency of small
allocations and allow the scaled font to reserve a single MRU page of
glyphs. This caching dramatically reduces the cairo overhead during the
cairo-perf benchmarks, and drastically reduces the number of allocations
made by the application (for example browsing multi-lingual site with
firefox).
