An older variant of the fixes for moving the device transformation out
of the surface layer, but languished in a side branch. The only benefit
of this patch is that it avoids the copy where possible.
When the texture is GL_RGB, GL_CLAMP_TO_BORDER (EXTEND_NONE) fills the
border color alpha channel with 1, when the whole reason we were using
the border color was to get a color and alpha of 0. We're forced to
use GL_RGBA textures and do extra work to fill in the alpha channel of
them to 1 to get cairo's desired behavior.
This fixes a failure in rotate-image-surface-paint and 4 other
testcases. No performance difference in firefox-talos-gfx.
Hanno Meyer-Thurow reported in
http://bugs.freedesktop.org/show_bug.cgi?id=26063
[PATCH] various fixes to cairo-qt
a few issues related to _cairo_qt_surface_flush() where firefox was
crashing after being built to use cairo-qt.
This is an amalgam of those patches that hopefully address the issue.
Fixes: test/linear-uniform
https://bugzilla.mozilla.org/show_bug.cgi?id=539165
Bug 539165 - gradients with a single stop do not have their color
multiplied by the alpha.
As reported by Jeff Muizelaar, we regressed in 2d790daa as the
color-stops are not premultiplied and so could not be treated as an
ordinary cairo_color_t. Instead we have to create a intermediate
cairo_color_t from the original values in order for the
premultiplication to be performed.
Jeff reported a regression found by Mozilla whereby a uniform gradient
was not being premultiplied on conversion to a solid pattern.
https://bugzilla.mozilla.org/show_bug.cgi?id=539165
[Bug 539165] gradients with a single stop do not have their color
multiplied by the alpha.
Quartz doesn't try to approximate dash pattern even if they are well
beyond suface sampling frequency. Approximating dash patterns when their
density is too high avoids looping indefinitely in these degenerate cases.
Ultimately, we want all of our paths to use shaders when they are
exposed -- it brings us closer to GL 3.0 compatibility and it should
reduce the work that GL drivers have to do per operation to compute
the required hardware state.
The whole point of making the mask was to avoid overwriting one glyph
with the data from another. Whoops.
Fixes ft-show-glyphs-positioning, text-rotate, overlapping-glyphs,
clip-text.
Failing to do so meant that we might not re-bind the framebuffer to
the correct one if we didn't follow up surface creation with drawing
to it.
Fixes many testcases. Thanks to T. Zachary Laine for tracking down
that the current_target was the source of these issues.
Normally is_clear is cleared by the caller of one of the 5 basic
entrypoints, but in this temporary surface usage nobody else can do it
for us.
Fixes ft-show-glyphs-table, user-font-rescale, and select-font-face.
Bug 26010 - cairo_line_to optimizes away path segments
http://bugs.freedesktop.org/show_bug.cgi?id=26010
As exercised by path-stroke-twice, we incorrectly optimise away a line
segment if the path doubled back upon itself. This is very reminiscent
of the optimisation bug for replacing curve-to with line-to.
mpsuzuki spotted that the output stream for the subset was not being
destroyed on the error path - on closer inspection, it wasn't destroyed
along the normal path either and may never have been correctly
initialised to NULL on an earlier error.
Reported-by: mpsuzuki@hiroshima-u.ac.jp
The number of points in a triangle fan was miscomputed because
it was computing the number of line segments rather than points
in the fan. Now we include the final point of the fan correctly
in the count.
This fixes https://bugs.webkit.org/show_bug.cgi?id=33071 as
reported by Benjamin Otte. A derived test case was not added
to the cairo test suite since the bug is difficult to trigger in
a reliable way which causes visible results (as opposed to
silent heap corruption.)
The easiest way of triggering the bug is to stroke a line
using a large line width and round caps or joins.
We have a test case get-and-set which wants to see whatever it puts
into a cairo_t come back out again, but at the same time cairo-gstate
wants to range reduce the dash offset it's given to a sane range.
This patch changes the range reduction algorithm to always normalize
to a non-negative dash offset and not touch dash offsets which are
already in range.
A recent optimisation has added a flag to the image
surface which is used to track whether the surface
is clear or not. This makes it imperative that clients
call cairo_surface_mark_dirty() if they use cairo to
allocate their pixel buffers and then proceed to
initialize them without telling cairo about it.
PDF requires a '\n' between the end of stream data and the "endstream"
that is not included in the stream length. Ensure this is always added
in _close_stream where it is not included in the stream length.
Previously the jpeg/jp2 embedding functions were adding the '\n'. This
resulted in the '\n' becoming part of the stream data.
Whilst investigating:
Bug 31788: SVG <line> with y1 == y2 and both with fractional
part don't render
https://bugs.webkit.org/show_bug.cgi?id=31788
I found that it can be reduced to a no-op clip following a no-op stroke
or fill. These conditions are exercised here and are shown to be a bug
introduced in the 1.9.x development series.
Add some auxiliary functions to cairo-stroke-style to compute
properties of the dashed patterns (period, "on" coverage) and to
generate approximations when the dash pattern is sub-tolerance.
These functions are used in cairo-path-stroke to simplify dash
patterns stroked by cairo.
Fixes dash-infinite-loop
See http://bugs.freedesktop.org/show_bug.cgi?id=24702
The infinite loop problem in _cairo_stroker_dash_start is solved by
commit ee02f3484899527380df94c00f40da87f41660ea, so hitting that
problem is not possible anymore and dash-infinite stroke always
hit the memory intensive loops.
This reverts commit 29432d3d32.
The stroke offset was forced to be positive because stroking code
wants to be able to decrement it until it finds the first dash to be
drawn. This can lead to long (almost infinite) loops if the offset is
positive but huge compared to the total length of the dash pattern.
Computing the offset this way guarantees that it's always the smallest
non-negative equivalent offset.
When computing an equivalent offset, a wrong total dash length was
used when the dash elements were odd and more than 1.
Doubling the total dash length whenever they are odd is needed to
correctly compute the new offset.
Fixes dash-offset.
