The rationale behind this change is that when someone is trying to
draw on a SVG surface using image surface patterns, the resulting SVG
file can take up to ridiculous 20 megabytes for 3-4 typical
photographic images in a single SVG file. This also can take
significant amount of CPU time to complete.
The reason for this behaviour is that currently whenever SVG backend
needs to emit an image tag for a surface pattern it takes a snapshot
of the subject surface, encodes it in PNG, then Base64-encodes and
emits the (huge) resulting string. With use of
cairo_surface_set_mime_data API this can be somewhat improved by
associating JPEG image contents with the corresponding surfaces.
Still this doesn't allow for post-processing of involved photographic
images without regenerating the SVG file.
As SVG specification allows URIs in the image tag's xlink:href
attribute, it is possible instead of embedding encoded image data to
simply link image files residing physically on the same medium as the
generated SVG file: files on disk under common directory, files on a
web server at common base URI, etc.
To make this happen we add new (unofficial) MIME type "text/x-uri" and
let users associate URIs with surfaces through
cairo_surface_set_mime_data() API. When SVG backend needs to emit
surface contents and it sees "text/x-uri" attached to the surface, it
emits this data instead of taking snapshot. The URI data is emitted
as is, so correctness check is left solely to the client code.
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.
The image surface tries to convert surface pattern's extend
modes to EXTEND_NONE, if it can, when converting a cairo_pattern_t
to a pixman_image_t. The check was not taking into account the
transformation matrix on the pattern, so it was possible to
trick it into using EXTEND_NONE by downscaling the source
pattern enough. This patch changes the optimization to only
take if the pattern has no transformation.
Fixes surface-pattern-scale-down-extend-{pad,reflect,repeat}
failures in the test suite for the image backend.
The slim_hidden_* macro definitions are rather cryptic at first
sight and I keep needing to rederive how they work just find out
what they're supposed to do. This patch adds a comment explaining
how they're used and work.
Split into a general cairo_image_surface_coerce() that coerces to one of
the 3 supported formats (ARGB32, RGB24, A8) based on content and the
more general cairo_image_surface_coerce_to_format() that coerces to a
specified format.
Benjamin Otte tracked down an invalid read triggered by WebKit. The
cause is that we attempt to dereference the list_head as an edge as we
failed to check that during the skipping of colinear edges we advanced
to the end, under the false assumption that there would always
be a closing edge in a rectangle. This assumption is broken if the tail
rectangles having colinear right edges.
Change the operator used to upgrade the format of a glyph mask from
CAIRO_OPERATOR_SOURCE to CAIRO_OPERATOR_ADD.
The _cairo_scaled_font_show_glyphs() function upgrades the pixel
format of a glyph mask by calling _cairo_surface_composite() to copy
the mask to an image surface of the upgraded destination. The way it
was doing it however was to use CAIRO_OPERATOR_SOURCE, a white source
pattern and the glyph's rasterised glyph as the mask pattern. This
combination isn't supported by _cairo_surface_composite(), which
asserts that no mask is present when the operator is SOURCE or CLEAR.
Reported by Mikael Magnusson to #cairo on irc.freenode.net.
Since moving to pixman for the gradient textures, first=0 and last=1,
so there's no need to rescale to 0,1 any more. Shaves 6 Gen4 ISA
instructions, including 2 inverses, in the radial fragment shader.
Creates a texture and draws with it instead of doing TexSubImage.
Open question is whether this wouldn't be better in general. Fixes
several failures with ARB_texture_rectangle path due to fallbacks to
window drawing.
Most testcases are now passing like the ARB_texture_non_power_of_two
case. EXT_texture_rectangle support is dropped in favor of
ARB_texture_non_power_of_two. If we have issues with drivers not
having that but having EXT (which just lacks the GLSL part of the
spec), we can split it out. Right now non-GLSL support in cairo-gl is
probably in bad shape anyway and will require someone that cares for
it in order to get fixed up.
The only issue is the repeat modes aren't supported for rectangular
textures. In any case even with ARB_npot radeon's pre-r600 lie and
fail to do repeats anyway.
This code is stolen straight from cairo-drm-intel.c. This saves a
bunch of time calculating interpolated points when we just do
interpolation between points at sampling time anyway. Reduces
firefox-talos-svg from 47 seconds back to the 42 it was at before the
pixman change.
This regresses the reported result of huge-radial, but there's no
visible difference.
... and fix the compile errors from it I get on my build.
It's Cairo style to put declarations before the code, so better warn
about it.
Besides, it eases porting to old compilers like MSVC.
If a signal interrupts the SET_TILING ioctl, the tiling and stride
values are updated to reflect the current condition of the buffer, so we
need to restore those to the desired values before repeating the ioctl.
This is significantly cribbed from Zach Laine's work, but reworked so
that gradients can be plugged in as either source or mask operands for
any of the paths.
This is significantly cribbed from Zach Laine's work, but reworked so
that gradients can be plugged in as either source or mask operands for
any of the paths.
This cuts the runtime of firefox-talos-svg in half on my GM45, at the
expense of gradient-alpha. surface-pattern-operator also now fails
due to small rasterization differences.
Rather than have fragment shaders try to walk a variable-length set of
stops and try to compute the interpolation between the nearest stops
per fragment, we make a little texture representing the gradient along
a line and have the shaders compute texture coordinates along the line
and sample. This should be a good tradeoff between CPU work and GPU
work.
[anholt: I pulled this set of code out of Zach Laine's tree to use for
gradient acceleration, and wanted to make sure attribution was
appropriate. I applied only minor tweaking]
