There appears to be a bug in some X servers which is triggered by
rendering 1-bit glyphs with zero size via the functions
XRenderAddGlyphs and XRenderCompositeText8 (and likely its variants).
We avoid this bug by making a copy of the glyphs array which does not
include any of the size-zero glyphs so that the X server never sees them.
This is an attempt to fix the following bug:
http://bugzilla.gnome.org/show_bug.cgi?id=332266
With the recent rewrite of the device-offset code, which pushed things
from the gstate to the surface layer, the 16-bit limitations on coordinates
which previously applied to device space only, have lately been applying to
user space. This commit moves the device_transform back up above the conversion
from floating-point to fixed-point values so that once again the limitation
only applies to device space.
When accessing the underlying drawable etc of an xlib surface, it is
also helpful to be able to get the width and height without a server
round trip. This patch provides those functions.
When the glyph format does not match the font format, the glyph will
be rendered incorrectly. Setting the {x, y}_offset correctly when
converting glyph format fix that.
This is a step toward allowing device scaling in addition to device offsets.
So far, the scale values are still always 1.0 so only the translation is
actually being used. But most of the code is in place for doing scaling as
well and it just needs to be hooked up.
There are some fragile parts in this code, all of which involve using the
translation without the scale, (so grep for device_transform.x0 or
device_transform->x0). Some of these are likely bugs that will hopefully
be obvious once we start using the scale. Others are OK if only because
we 'know' that we aren't ever setting device scaling on a surface that
has a device offset (we only set device scaling on surfaces we create
internally and we don't export device scaling to the user).
All of these fragile parts in the code have been marked with comments of
the form: XXX: FRAGILE.
Global advance exists for historical reasons. Nowadays, most of fonts
support unicode, means it's no guaranteed to every glyphs in the font
has the same advance.Sometimes it maybe is biger/smaller then the global
advance even for monospace fonts!So forcing their advance to global
advance, it's obviously wrong.
This rectangle has regular integer values, not fixed-point values.
So the old name was horribly wrong and misleading, (and yes I think
it was even I that had suggested it).
This patch was produced by running git-stripspace on all *.[ch] files
within cairo. Note that this script would have also created all the changes
from the previous commits to remove trailing whitespace.
This patch was produced with the following (GNU) sed script:
sed -i -r -e 's/[ \t]+$//'
run on all *.[ch] files within cairo.
Note that the above script would have also created all the changes
from the previous commits to remove trailing whitespace.
This patch was produced with the following (GNU) sed script:
sed -i -r -e '/^[ \t]*\/?\*/ s/[ \t]+$//'
run on all *.[ch] files within cairo, (though I manually excluded
src/cairo-atsui-font.c which has a code line that appears as a comment
to this script).
xlib_show_glyphs was always calculating the glyph extents, even when it
didn't need to; this only does it when necessary.
Also adds an implementation of surface_flush() for xlib that just calls
XSync.
(cherry picked from 8770ac5b5cdba8007c4c6a6a980e6e06acf6aeb6 commit)
Avoid using the fallback paths as much as possible; implement real
show_glyphs, falling back for OPERATOR_SOURCE (due to Render bug), and all
unbounded operators (let the fallback code deal with fixup). Also fall
back if we have a fallback mask clip set.
(cherry picked from 3225a4ec820fd4051dd893ffc4258b182bd62dca commit)
Including style cleanups for _xrender_format_matches_content.
There's even a bug fix here as well. Previously, we would miss compatibility
if the existing xlib surface had a NULL visual, (even if it had a compatible
xrender_format). We now catch this case, and don't bother even trying to
store a visual into the resulting surface.
I recently discovered that cairo_create_similar on a 16-bit xlib surface
creates a surface backed by a 24-bit pixmap. This results in absymal
performance --- I can actually watch a copy from the similar to the
original move down the screen, on my dual Xeon, NVidia vendor driver
machine. It also means xlib-based code like GTK themes can't render to
the surface because it doesn't match the screen depth.
The attached patch makes _cairo_xlib_surface_create_similar match the
characteristics of the input surface as closely as I know how, and fixes
my issues.
This is a mega-patch that has the advantage that the entire test suite
passes both immediately before and immediately after this commit.
The disadvantage of the mega-patch is that it does not reflect the
development history of the device-offset branch, (with its various
fumblings and flailings). To capture that history, we will next merge
in that branch.
If we find a glyph image of a format that is different from the font's
format, then we use a temporary image and convert to the font's
format.
This provides a simple fix for the crash identified in bug #4705:
crash at XRenderAddGlyphs
https://bugs.freedesktop.org/show_bug.cgi?id=4705
A later improvement would guarantee that the "font's format" was
carefully chosen to be able to contain all glyphs in the font without
information loss.
Bogus fix; misunderstood the relationship between the font bearings
and the computed device offsets. Real fix on my device offsets branch.
This reverts 49b4fe10d0 commit.
cairo-ft-font was being naughty and storing glyph bearings in the
surface device_[xy]_offset fields -- this had no effect previously,
because _cairo_surface_composite ignored those fields, but once it
starts handling device offsets itself, this causes ft text rendering
to break.
Track changes in surface backend from fill_path to fill.
Track the new canonical argument naming and ordering for the 5 drawing operations.
Move various stroke style settings into new cairo_stroke_style_t.
Drop NULL fill_path backend function which no longer exists.
Split CARIO_EXTEND_DEFAULT to indicate defaults for surfaces and gradients. The default for gradients is still the NEAREST beaviour.
Support the NEAREST mode, change NONE to be TRANSPARENT.
Update the extend mode code to use the pixman support.
Handle NEAREST, note that support for NONE is not yet handled for gradients.
Add a check for NEAREST but don't do anything useful.
Add a check for NEAREST but don't do anything useful.
Update a comment about the extend support in the image backend.
reviewed by: davidr, cworth, otaylor
