We need to translate the path in order to compensate for the device offset
applied to the group surface when pushing and popping. (The path is
transformed to device space on creation, and so needs recomputing for the
new device.)
A cairo context is meant to be extremely cheap to create such that it can
be used in transient expose events. Thus these are allocated reasonably
frequently and show up malloc profiles.
When observing applications two patterns emerge. The first is due to
Pango, which wraps each glyph run within a context save/restore. This
causes the scaled font to be evicted after every run and reloaded on the
next. This is caught by the MRU slot on the cairo_scaled_font_map and
prevents a relatively costly traversal of the hash table and holdovers.
The second pattern is by applications that directly manage the rendering
of their own glyphs. The prime example of this is gnome-terminal/vte. Here
the application frequently alternates between a few scaled fonts - which
requires a hash table retrieval every time.
By introducing a MRU slot on the gstate we are able to directly recover
the scaled font around 90% of the time.
Of 110,000 set-scaled-fonts:
4,000 were setting the current font
96,000 were setting to the previous font
2,500 were recovered from the MRU on the cairo_scaled_font_map
7,500 needed a hash retrieval
which compares to ~106,000 hash lookups without the additional MRU slot on
the gstate.
This translates to an elapsed time saving of ~5% when replaying a
gnome-terminal trace using the drm backend.
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.
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
Profiling a silly video renderer that called set-source; rectangle; fill;
for each pixel, we can shave 5% off the cairo overhead by introducing an
early return if we attempt to reset the current colour.
Sascha Steinbiss reported a bug where the PDF backend was reading beyond
the end of the glyph array:
http://lists.cairographics.org/archives/cairo/2008-December/015976.html.
It transpires that in the early glyph culling in the gstate we were
not updating the clusters to skip culled glyphs.
When computing the bounds of the clip path, we care more for a fast result
than absolute precision as the extents are only used as a guide to trim
the future operations. So computing the extents of the path suffices.
First try to use a stack buffer for the glyphs and clusters if the user
calls cairo_show_text() - for example, as pango does to draw the unknown hex
box.
When discussing the implications of snapshot cow, one of the questions
that we raised was what happens on cairo_destroy()? The lifetime of the
context implicitly marks the extents of the drawing operations, typically
the expose event (or perhaps one phase of it). Therefore at the end of the
sequence we implicitly wish to flush the graphics events to the surface.
Avoid allocating a default source pattern by using the static black pattern
object. The one complication is that we need to ensure that the static
pattern does leak to the application, so we replace it with an allocated
solid pattern within _cairo_gstate_get_source().
With the addition of cairo_show_text_glyphs() came a couple of functions
to query whether the target supported the extended attributes. However,
at Carl's request cairo_has_show_text_glyphs() was removed - but the
documentation was not updated to reflect that.
The release notes for 1.7.6 say that we had dropped this
function, but apparently we had only planned to do that
and didn't actually get around to it until now.
Thanks to the RELEASING insctructions which gave a diff
command that pointed out this problem.
Chris rightfully complained that having a boolean function argument is
new in cairo_show_text_glyphs, and indeed avoiding them has been one
of the API design criteria for cairo. Trying to come up with alternatives,
Owen suggested using a flag type which nicely solves the problem AND
future-proofs such a complex API.
Please welcome _flags_t APIs to cairo.h
We added cairo_has_show_text_glyphs() before. Since this is really a
surface property, should have the surface method too. Like we added
cairo_surface_show_page()...
And update user-font text_to_glyphs() method to match.
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.
When popping a group, transform it by the ctm centered at the origin
specified by the device_transform so that it ends up in the right place
when we try to paint. This fixes the regressions caused by
1a9809baab as shown by the pdf backend.
