Adds a new, fake, fontconfig font backend. Fontconfig can be disabled
using --disable-fc, in which case the toy text API wont find fonts and
the internal font will always be used.
Also defines the feature macro CAIRO_HAS_FC_FONT. The two fontconfig-specific
functions in cairo-ft.h depend on that macro now.
Jeff Muizelaar pointed out that the severe overallocation implicit in the
current version of the glyph cache is obnoxious and prevents him from
accepting the trunk into Mozilla. Jeff captured a trace of scaled font
and glyph usage during a tp run and presented his analysis in
http://lists.cairographics.org/archives/cairo/2009-March/016706.html
Using that data, the design was changed to allocate pages of glyphs from a
capped global pool but with per-font hash tables. This should allow the
glyph cache to have tight memory bounds with fair allocation according to
usage. Note that both the old design and the 1.8 glyph cache had
essentially unbounded memory constraints, since each scaled font could
cache up to 256 glyphs (1.8) or had a reserved page (old), with no limit
on the number of active fonts. Currently the eviction policy is a simple
random strategy, this gives a 'fair' allotment of the cache, but a LRU
variant might perform better.
On a sample run of firefox-3.0.7 perusing BBC news in 32 languages:
1.8: cache allocation 8190x, ~1.2 MiB; elapsed 88.2s
old: cache allocation 771x, ~13.8 MiB; elapsed 81.7s
lean: cache allocation 433x, ~1.8 MiB; elapsed 82.4s
Applications like firefox have a very conservative approach and mark
surfaces dirty before every render. As we record the image data every
time, firefox traces can grow very large with redundant data - so allow
the user to disable mark dirty tracing.
Intialize 'interpolate' to prevent a gcc warning. Do this instead of adding a
'default' case to the switch statement so that we still get warnings if new
filter types are added.
Eliminate the need for a runtime test on the sizeof the private structures
by performing the check at compile time. This was provoked by Ginn Chenn
noting that the test was including a private header.
It doesn't work for non GCC compiler right now, as "-Werror -Wall" is
an error to non GCC compiler.
I swapped the sequence of build/configure.ac.system and build/
configure.ac.warnings, then WARN_CFLAGS can be used.
Jeff Muizelaar found a regression in commit 005436 and submitted this
little test to exercise it. The essence of the bug appears to be wrt to
the product of the CTM and device transform matrices.
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.
toy-font-face was checking that cairo_toy_font_face_get_family returned ""
which is CAIRO_FONT_FAMILY_DEFAULT when the freetype font backend is the
default. However, when other font backends are the default the returned family
is different. Therefore, instead of checking for "", we check for the appropriate
string depending on the backend.
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
