This is a common format used by framebuffers to drive 10bpc displays
and is often hardware accelerated by XRender with underlying support
from pixman's x2r10g10b10 format (which provides coercion paths for
fallbacks).
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is consistent with the naming of most cairo types/functions
(example: cairo_foo_surface_*).
The substitution in the code has been performed using:
sed -i 's/cairo_pattern_mesh_/cairo_mesh_pattern_/' <files>
The reuse hit rate is very small, and most images are quickly
distinguished in the first few bytes... Though perhaps not for video as
in the swfdec-youtube case...
After a renewed discussion, it was pointed out that the API in Cairo was
not restrictive and by using doubles we would be consisted with the rest
of the API. Thus prompting the name change to
cairo_surface_create_for_rectangle()
similar to cairo_rectangle().
And document the public API.
I updated the Free Software Foundation address using the following script.
for i in $(git grep Temple | cut -d: -f1 )
do
sed -e 's/59 Temple Place[, -]* Suite 330, Boston, MA *02111-1307[, ]* USA/51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA/' -i "$i"
done
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=21356
When compiling we can depend on whatever version of cairo we need, but
we should be wary of checking for runtime compatibility when building
standalone.
We were exposing the actual value of CAIRO_FORMAT_INVALID
through API functions already, so it makes sense to just
go ahead and put it in the cairo_format_t enum.
Should fix:
Bug 26509 - Cairo fails to compile without mmap
http://bugs.freedesktop.org/show_bug.cgi?id=26509
As reported by Hib Eris, Cairo files to compile under a mingw32
cross-compiler as we use a structure only defined if HAVE_MMAP
unconditionally.
By implicitly reference the target of the context instead, i.e.
this reduces the use of:
/target get (example.png) write-to-png pop
as a common idiom where the context is kept on the stack and the surface
forgotten.
Real applications that control their Drawable externally to Cairo are
'disadvantaged' by cairo-perf-trace when it creates a similar surface
for each new instance of the same Drawable. The difficulty in
maintaining one perf surface for every application surface is that the
traces do not track lifetimes for the application surfaces, so we would
just accumulate stale surfaces. The surface cache takes a different
approach and returns the same surface for each active Drawable, and
maintains a hold-over of the MRU 16 surfaces. This achieves 60-80% hit
rate with firefox, which is probably as good as can be expected.
Obviously for double-buffered applications we only every draw to freshly
created surfaces (and Gtk+ bypasses cairo to do the final copy -- the
ideal application would just use a push-group for double buffering, in
which case we would capture and replay the entire expose event).
To enable use of the surface cache whilst replaying use -c:
./cairo-perf-trace -c firefox-talos-gfx
In order to get a baseline for win32 performance testing, always create a
font so that the trace can be replayed. Not ideal, but I feel this the
pragmatic solution for judging the performance differentials before I can
work out a better solution for loading typ42 fonts.
In order to enable replay of traces on machines that do not use FreeType
as the native font system, we need to convert a type42 font into something
similar. Currently the fallback is just to select a font with the same
name - this ignores weight and slant, and many other details.
Kerning is quite frequent, that is to apply a horizontal but no vertical
offset to a glyph. For instance by discarding the vertical coordinate
where it remains the same and only encoding the horizontal offset we
reduce the file size by ~12.5% when tracing poppler.
If we fail to add the glyph cache (presumably because the font is in
error) do not leak the allocation. As this occurs for every single glyph
string, the leak can grow very quickly and mask the original bug.
After diverting the pointers to accommodate lazy decompressing of the
source, the bytecode pointer was left pointing to the original location
that had already been freed - thus passing an invalid block to FreeType
and unsurprisingly then, blowing up.
Hook into the scanner to write out binary version of the tokenized
objects -- note we bind executable names (i.e. check to see if is an
operator and substitute the name with an operator -- this breaks
overloading of operators by scripts).
By converting scripts to a binary form, they are more compact and
execute faster:
firefox-world-map.trace 526850146 bytes
bound.trace 275187755 bytes
[ # ] backend test min(s) median(s) stddev. count
[ 0] null bound 34.481 34.741 0.68% 3/3
[ 1] null firefox-world-map 89.635 89.716 0.19% 3/3
[ 0] drm bound 79.304 79.350 0.61% 3/3
[ 1] drm firefox-world-map 135.380 135.475 0.58% 3/3
[ 0] image bound 95.819 96.258 2.85% 3/3
[ 1] image firefox-world-map 156.889 156.935 1.36% 3/3
[ 0] xlib bound 539.130 550.220 1.40% 3/3
[ 1] xlib firefox-world-map 596.244 613.487 1.74% 3/3
This trace has a lot of complex paths and the use of binary floating point
reduces the file size by about 50%, with a commensurate reduction in scan
time and significant reduction in operator lookup overhead. Note that this
test is still IO/CPU bound on my i915 with its pitifully slow flash...
These can be reasonably large and persist for long times due to the
font holdover caches, so manually swap them out to save space on tiny
swapless machines.
As an aide to tiny swapless systems write the rarely used bytes that
define type42 fonts into a deleted file and mmap them back into our
address space.
Seeing unexpected time inside pixman composite is quite disturbing when
trying to track down the apparent slowness in some benchmarks. Remove one
source of this artefact by simply memcpy'ing pixel data when trivial.
The glyph advance cache was only enabled for glyph indices < 256,
causing a large number of misses for non-ASCII text. Improve this by
simply applying the modulus of the index to select the cache slot - which
may cause some glyph advances to be overwritten and re-queried, but
improves the hit rate.
Bah, the compiler failed to do its IPA correctly and wrongly complained
about potential use of uninitialised out-params guarded by the return
value. Silence them!
Frequently to push an object onto the stack all we need is to simply
perform the struct copy - so inline it and only call the out-of-line
function if we need to enlarge the stack.
