| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Specifically check for an error during resolving the font and do not cache
the error object.
|
|
Handling clip as part of the surface state, as opposed to being part of
the operation state, is cumbersome and a hindrance to providing true proxy
surface support. For example, the clip must be copied from the surface
onto the fallback image, but this was forgotten causing undue hassle in
each backend. Another example is the contortion the meta surface
endures to ensure the clip is correctly recorded. By contrast passing the
clip along with the operation is quite simple and enables us to write
generic handlers for providing surface wrappers. (And in the future, we
should be able to write more esoteric wrappers, e.g. automatic 2x FSAA,
trivially.)
In brief, instead of the surface automatically applying the clip before
calling the backend, the backend can call into a generic helper to apply
clipping. For raster surfaces, clip regions are handled automatically as
part of the composite interface. For vector surfaces, a clip helper is
introduced to replay and callback into an intersect_clip_path() function
as necessary.
Whilst this is not primarily a performance related change (the change
should just move the computation of the clip from the moment it is applied
by the user to the moment it is required by the backend), it is important
to track any potential regression:
ppc:
Speedups
========
image-rgba evolution-20090607-0 1026085.22 0.18% -> 672972.07 0.77%: 1.52x speedup
▌
image-rgba evolution-20090618-0 680579.98 0.12% -> 573237.66 0.16%: 1.19x speedup
▎
image-rgba swfdec-fill-rate-4xaa-0 460296.92 0.36% -> 407464.63 0.42%: 1.13x speedup
▏
image-rgba swfdec-fill-rate-2xaa-0 128431.95 0.47% -> 115051.86 0.42%: 1.12x speedup
▏
Slowdowns
=========
image-rgba firefox-periodic-table-0 56837.61 0.78% -> 66055.17 3.20%: 1.09x slowdown
▏
|
|
We are expected to return a new reference from get_implementation(), and
failing to do so was causing use-after-frees (detected by the reference
counting checks).
|
|
Keep the resolved font face alive whilst the default FcConfig remains
identical i.e. resolve the pattern again if the system configuration
changes (e.g. a new font is added or the rules are updated). This should
retain the benefits of lazily resolving font patterns whilst improving
performance by reducing the number of calls to FcFontMatch().
|
|
Fixes bug 22356 -- Spurious "out of memory" error on system without fonts
https://bugs.freedesktop.org/show_bug.cgi?id=22356
If FcFontMatch() fails, then it means that there are no fonts available on
the system (or it may have been a malloc error, we have no way of telling).
Instead of report NO_MEMORY and disabling all drawing, one of the
rationales for including a builtin font was so that we could continue even
in the face of this error and show *something* to the user. (This being a
last resort (and especially important for demos!) and hopefully easier to
diagnose than no output at all.)
|
|
The lazy resolution of patterns was defeating the scaled_font cache as
ft-fonts that resolved to the same unscaled font were being given different
font-faces upon creation. We can keep the lazy resolution by simply asking
the ft backend to create a fully resolved ft-font-face when we need to
create a scaled-font. This font is then keyed by the resolved font-face
and so will match all future lazily resolved identical patterns.
|
|
|
|
_font_map_release_face_lock_held() was being called unconditionally during
_cairo_ft_font_reset_static_data(). This presents two problems. The first
is that we call FT_Done_Face() on an object not owned by cairo, and the
second is that the bookkeeping is then incorrect which will trigger an
assert later.
|
|
|
|
As an aide to tracking down the source of uninitialised reads, run
VALGRIND_CHECK_MEM_IS_DEFINED() over the contents of image surfaces at the
boundary between backends, e.g. upon setting a glyph image or acquiring
a source image.
|
|
Bug 21706 -- zombie ft_font_face / ft_unscaled_font mutual
referencing problems
[http://bugs.freedesktop.org/show_bug.cgi?id=21706]
There can be more than one zombie font_face belonging to an unscaled_font,
but only the first is destroyed. This leaks the client's FT_Face
(and associated font data) as release of the FT_Face depends on release
of the font_face.
(The reason why Firefox ends up with two different font_faces for one
unscaled_font is that load_flags for faces with artificial oblique have
FT_LOAD_NO_BITMAP set.
https://bugzilla.mozilla.org/show_bug.cgi?id=486974)
Also it's possible for _cairo_ft_font_face_create to pull out a zombie
font_face from the unscaled_font, which would crash
_cairo_ft_font_face_scaled_font_create, as that expects non-null
font_face->unscaled (if !font-face->pattern).
|
|
I broke the ability for the ft font backend to resolve patterns whilst
fixing the font creation to propagate the error status from fontconfig
(be27e8). By adjusting the sequence of error checks we do not confuse
the absence of a match with a fatal error and thereby restoring the
lazy pattern resolution whilst ensuring error propagation.
|
|
Return the true error status whel
_cairo_ft_unscaled_font_create_internal(). This ensures that the original
error is not masked and we are able to report the error during fontconfig
pattern resolution.
|
|
Check the return of FcPatternDuplicate() for failure, and propagate the
error.
|
|
Check the return from FcPatternDuplicate() for allocation failure (and not
the original pattern)!
|
|
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
|
|
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.
|
|
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.
|
|
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.
|
|
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>
|
|
Don't use the remarkably inefficient _cairo_hash_table_random_entry() to
remove all entries from the hash table!
|
|
|
|
|
|
This commit moves the toy-to-real mapping from the scaled font creation
time to font face creation. A toy font face will keep an internal ref
to an implementation face. Then cairo_scaled_font_create() will simply
substitute the implementation face before creating anything.
This also modifies the cairo-ft toy creation in that we now create a
non-resolved pattern and store it in a cairo-ft font-face. We then
do the resolving and unscaled font creation at scaled-font creation
time. This also means that cairo_ft_font_face_create_for_pattern()
now accepts non-resolved patterns too, and does the right thing about
them. As much as that can be called right.
Some testing of toy font creation performance is in order, as is testing
win32 and quartz font backends.
|
|
Use the gcc likelihood annotation to indicate that allocation failures are
extremely unlikely.
|
|
The error paths should be hit very rarely during normal operation, so mark
them as being unlikely so gcc may emit better code.
|
|
A new meta-surface backend for serialising drawing operations to a
CairoScript file. The principal use (as currently envisaged) is to provide
a round-trip testing mechanism for CairoScript - i.e. we can generate
script files for every test in the suite and check that we can replay them
with perfect fidelity. (Obviously this does not provide complete coverage
of CairoScript's syntax, but should give reasonable coverage over the
operators.)
|
|
Use the return value to return the result from _cairo_hash_table_lookup()
(as opposed to filling an output parameter on the stack) as this (a)
results in cleaner code (no strict-alias breaking pointer casts), (b)
produces a smaller binary and (c) is measurably faster.
|
|
Quartz fonts and user fonts use an indirect font face when creating a
scaled font for the toy font face. This means that they insert a scaled
font into the font map that has a different font face to the one that is
initially searched upon. The result is that when we try to create an
identical scaled font, we fail to find the existing scaled font and
attempt to insert a duplicate into the hash table - which triggers an
assert.
In order to avoid creating duplicate fonts, we add a new method to the
font backends that allows cairo_scaled_font_create() to peek at the
font_face that will be used to actually implement the scaled font
constructor - thus we are able to use the correct font_face as part of the
hash key.
|
|
Currently we only have an example of how to call FT_Done after the last
reference to the FT cairo_font_face_t has been dropped, but do not
actually explain why this needs to be done. So add a couple of sentences
to clarify the likely lifetime of the FT_Face once exposed to cairo.
|
|
We reverted the public API for setting lcd_filter font options
back in 1b42bc8033bc , but we had left the implementation which
would examine fontconfig and Xft properties for the option, and
which would call into freetype for subpixel glyph rasterization.
However, I recently realized, (and the test suite had been trying
to tell me for a while), that this approach would cause a
regression for users who were previously using sub-pixel text,
but without sub-pixel rendering built directly into freetype.
That's not acceptable, so all the code is coming out for now.
|
|
The bit-swapping macro uses the full register for intermediate storage so
we need to be careful to only read the low byte when using the result.
[Only the use in ps-surface.c was incorrect, I just converted the other
unsigned chars to uint8_t for consistency.]
|
|
_cairo_matrix_compute_basis_scale_factors
|
|
|
|
|
|
Value stored to 'stride' is never read.
|
|
No idea if Ubuntu will ever learn not to modify public API of
common libraries without any clue of what kind of problems they
create by doing that. They could very well define
FC_UBUNTU_LCD_FILTER if they wanted to, but no, they defined
FC_LCD_FILTER as if it's an upstream thing. It wasn't.
|
|
|
|
|
|
This adds define for compatibility when without the new lcd filtering
constants (Fontconfig patch not yet applied, see bug 13566).
|
|
|
|
This is the patch David Turner wrote some times ago and can be found on
http://david.freetype.org/lcd/cairo-1.2.4-lcd-filter-1.patch. It was
somewhat modified for compatibility with cairo 1.5
|
|
|
|
|
|
|
|
|
|
Recent change to the cache key had broken all caching as we were always
comparing unscaled->face.
|
|
|
