For every glyph evicted from the cache we would allocate a very small
structure to push onto the xlib work queue. This quickly becomes
noticably for an app that consumes a lot of scaled fonts and glyphs,
e.g. trying to draw text at various angles. So we maintain a small array
of glyphs pending finalisation and issue the XRenderFreeGlyphs() once the
array is full.
During the destruction of every font used with an xlib surface, we send
an XRenderFreeGlyphs() for every single glyph in the cache. These
requests are redundant as the server-side glyphs will be released along
with the XRenderFreeGlyphSet(), so we skip the individual glyph
destruction if the font is marked as finished.
XRender performs a round-trip in order to query the available formats on
the xserver, before searching for a matching format. In order to save
that round-trip and to avoid the short-lived allocation of the array of
available formats, we cache the result on the display.
As identified by Vladimir Vukicevic,
_cairo_xlib_surface_create_similar_with_format() was erroneously passing
down the source Visual when creating a surface with a different
XRenderPictFormat.
If the xserver doesn't support the RENDER extension or simply doesn't
have the matching PictFormat then xrender_format might be NULL. Check
and fallback in this case.
XRenderAddGlyph() does not split its image data across multiple requests
and so the glyph surface must be smaller than XMaxRequestSize or else
the server will disconnect the client, causing "Fatal IO error 104".
As this will require an extension to the XRender spec, we can work
around the issue by using our fallbacks if we detect that the glyph will
be too large for a single request.
See bugs https://bugs.freedesktop.org/show_bug.cgi?id=4339 and
http://bugs.freedesktop.org/show_bug.cgi?id=13266 for examples.
Previously, given a valid XRenderFormat the Visual was discarded
when creating similar surfaces. However the original Visual is
required to support reading back from non-TrueColor surfaces.
The compiler isn't clever enough to notice that these
variables are always initialized (in either the TrueColor
or ! TrueColor conditions corresponding to the later
identical conditions in which the variables are used).
This support involves allocating a 16-bit grayscale ramp as well
as a 5x5x5 RGB color cube. Afterwards, the 256 colors are queried
and an array is generated mapping from r3g3b3 colors to the closest
available color. Both the queried colors and the reverse mapping
are stored in a new visual-specific cairo_xlib_visual_info_t
structure which hangs off of the cairo_xlib_screen_info_t.
Both the color-cube allocation and the distance metric could be
improved by someone sufficiently motivated, (for example, allocating
and matching in a perceptually linear color space rather than just
in RGB space). Also, making this work well in the face of a changing
color map, or in the case of GrayScale, StaticGray, or DirectColor
visuals are left entirely as exercises for the reader. StaticColor
support should be fine as is, but is entirely untested.
We're moving the assertion up from inside _pixman_format_to_mask
to its callers. This will allow us to selectively eliminate the
assertion from the supported xlib backend, while leaving it in
the unsupported glitz and xcb backends for now.
Previously we were passing the root window of the same screen.
Letting the X server know the actual Drawable for which we're
trying to be similar allows the X server to be more efficient.
The NULL return value will only happen if the X Render extension
is not available. We've already got that NULL return value
documented, so it's not an error if the user asks for it. In
particular, it's definitely not a surface-type mismatch.
cairo_rectangle_int16_t was being used in a number of places instead
of cairo_rectangle_int_t, which led to memory corruption when cairo was
using a fixed point format with a bigger space than 16.16 (such as 24.8).
In http://bugs.freedesktop.org/show_bug.cgi?id=13699, Pavel Vozenilek
reports a duplicate define for computing the appropriate length for an
on-stack array. The macro in question, and a few other places, was
performing CAIRO_STACK_BUF_SIZE/sizeof(stack[0]) so we can simplify
them slightly by using a common macro.
We maintain three Xrender glyphsets per scaled font, one for each of A1, A8,
and ARGB32. This is required to correctly support fonts with bitmaps for
some glyphs but not all.
Do not rely on the assumption that if the destination has render support
then the source has it as well - breaks when the boilerplate disables
render support for a surface.
Similarly do not set the XRender attributes on the source surface
unless it actually has a xrender_format.
The reasoning is that right now, applications render glyphs to images,
upload it to the X server, and keep a local copy in the cache. The X
server works hard to reuse glyph renderings, by hashing glyph images and
reusing them. So we are wasting memory in cairo apps that don't use the
glyph surface after uploading to the server, which is the case if you
don't use the glyph in an image surface. The patch does not release the
glyph surface if it already existed in the cache, so, worst case
scenario is that we render the glyph twice, if you first use it with
xlib, then with image surface. That effect should be negligible.
_xrender_format_to_content() was using the channel offset to determine
whether the format supported a content type.
For example, the XRenderPictFormat for the A8 format looks like:
direct.alpha = 0; direct.alphaMask = 0xff;
direct.red = 0; direct.redMask = 0x00;
direct.green = 0; direct.greenMask = 0x00;
direct.blue = 0; direct.blueMask = 0x00;
which _xrender_format_to_content() matched as CAIRO_CONTENT_COLOR.
Switch to using the channel masks for deducing content type.
The VendorString parsing (to detect broken Xserver versions) was being
performed for each surface creation, but as it is a display invariant
we can save a small amount of work by storing the result on the
cairo_xlib_display_t.
Instead of simply ignoring the error that may occur when we upload the
destination image to the xlib surface (via XPutImage) record the error
on the xlib surface.
The xlib surface creation routines will eventually attempt to lock the
global _cairo_xlib_display_mutex. Under the default environment this is
a non-issue as the CAIRO_MUTEX_INITIALIZE/FINALIZE become no-ops under
pthreads. However, for the sake of correctness (i.e. to silence the
lockdep debugger!) insert a call to initialize the global mutexes at the
start of the public entry points.
Every time we assign or return a hard-coded error status wrap that value
with a call to _cairo_error(). So the idiom becomes:
status = _cairo_error (CAIRO_STATUS_NO_MEMORY);
or
return _cairo_error (CAIRO_STATUS_INVALID_DASH);
This ensures that a breakpoint placed on _cairo_error() will trigger
immediately cairo detects the error.
This reverts commit 919bea6dbb.
Sadly as Behdad points out some backends do modify the glyph array and,
for example cairo-xlib-surface, hide this from the compiler with some
evil casts.
Skip the memory duplication of the incoming glyphs if we do not need
to transform them into the backend coordinate system.
As a consequence we need to constify the glyphs passed to the backend
functions.
Previously, the code was just using cairo_format_t which is much more limited
than the formats supported by pixman, (so many "odd" X server visuals would
just fall over).
Seems like all over the code, we have been using negated device_offset
values for glyph surfaces. Here is all the math(!):
A device_transform converts from device space (a conceptual space) to
surface space. For simple cases of translation only, it's called a
device_offset and is public API (cairo_surface_[gs]et_device_offset).
A possibly better name for those functions could have been
cairo_surface_[gs]et_origing. So, that's what they do: they set where
the device-space origin (0,0) is in the surface. If the origin is inside
the surface, device_offset values are positive. It may look like this:
Device space:
(-x,-y) <-- negative numbers
+----------------+
| . |
| . |
|......(0,0) <---|-- device-space origin
| |
| |
+----------------+
(width-x,height-y)
Surface space:
(0,0) <-- surface-space origin
+---------------+
| . |
| . |
|......(x,y) <--|-- device_offset
| |
| |
+---------------+
(width,height)
In other words: device_offset is the coordinates of the device-space
origin relative to the top-left of the surface.
We use device offsets in a couple of places:
- Public API: To let toolkits like Gtk+ give user a surface that
only represents part of the final destination (say, the expose
area), but has the same device space as the destination. In these
cases device_offset is typically negative. Example:
application window
+---------------+
| . |
| (x,y). |
|......+---+ |
| | | <--|-- expose area
| +---+ |
+---------------+
In this case, the user of cairo API can set the device_space on
the expose area to (-x,-y) to move the device space origin to that
of the application window, such that drawing in the expose area
surface and painting it in the application window has the same
effect as drawing in the application window directly. Gtk+ has
been using this feature.
- Glyph surfaces: In most font rendering systems, glyph surfaces
have an origin at (0,0) and a bounding box that is typically
represented as (x_bearing,y_bearing,width,height). Depending on
which way y progresses in the system, y_bearing may typically be
negative (for systems similar to cairo, with origin at top left),
or be positive (in systems like PDF with origin at bottom left).
No matter which is the case, it is important to note that
(x_bearing,y_bearing) is the coordinates of top-left of the glyph
relative to the glyph origin. That is, for example:
Scaled-glyph space:
(x_bearing,y_bearing) <-- negative numbers
+----------------+
| . |
| . |
|......(0,0) <---|-- glyph origin
| |
| |
+----------------+
(width+x_bearing,height+y_bearing)
Note the similarity of the origin to the device space. That is
exactly how we use the device_offset to represent scaled glyphs:
to use the device-space origin as the glyph origin.
Now compare the scaled-glyph space to device-space and surface-space
and convince yourself that:
(x_bearing,y_bearing) = (-x,-y) = - device_offset
That's right. If you are not convinced yet, contrast the definition
of the two:
"(x_bearing,y_bearing) is the coordinates of top-left of the
glyph relative to the glyph origin."
"In other words: device_offset is the coordinates of the
device-space origin relative to the top-left of the surface."
and note that glyph origin = device-space origin.
So, that was the bug. Fixing it removed lots of wonders and magic
negation signs.
The way I discovered the bug was that in the user-font API, to make
rendering the glyph from meta-surface to an image-surface work I had
to do:
cairo_surface_set_device_offset (surface, -x_bearing, -y_bearing);
_cairo_meta_surface_replay (meta_surface, surface);
cairo_surface_set_device_offset (surface, x_bearing, y_bearing);
This suggested that the use of device_offset for glyph origin is
different from its use for rendering with meta-surface. This reminded
me of the large comment in the xlib backend blaming XRender for having
weird glyph space, and of a similar problem I had in the PS backend
for bitmap glyph positioning (see d47388ad75)
...those are all fixed now.
