Whilst testing the fallback surface, the resultant image was being
clipped to the screen size. Be conservative and refuse to create
windows (for CAIRO_CONTENT_COLOR surfaces) that are larger than the
screen.
As well as marking the XRender extension unavailable in
_cairo_boiler_player_xlib_disable_render(), we need to clear any
XRender derived information stored during the surface creation.
These were recently added, (as part of sparse integration?), but they
break boilerplate which reaches into at least cairo-types-private.h
and cairo-scaled-font-private.h. But boilerplate cannot see cairoint.h
or else it gets the internal sybol renaming, (with the INT_ prefix),
and then all the test suite tests refuse to link.
If this change reverts some recently-added functionality, (or
cleanliness), then we'll just need to find some other way to add that
back again without the breakage.
Apparently, our much-beloved error message, (just look at how many people
love to quote it in bugzilla entries), was removed during the switch to
the new pixman. It was replaced with an obscure failure of a nil surface
being returned, (leading to obscure failures or false "out of memory"
errors).
So we're putting this back now, (even though we _really_ want to ensure
that this message never gets printed in practice).
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).
This avoids a potential crash from the Render extension being cleaned
up during XCloseDisplay before the cairo CloseDisplay hook goes on to
call into XRenderFreePicture.
This isn't necessarily more correct than the old code using the doubles,
but it does result in bit-for-bit color equivalence when comparing the
results against the image backend. So that's both good consistency, and
more ease is using the test suite to verify things.
The analysis surface now keeps track of two regions: supported
operations, and unsupported operations. If the target surface returns
CAIRO_INT_STATUS_FLATTEN_TRANSPARENCY, the analysis surface will check
if any previous operation intersects with this operation. If there is
nothing previously drawn under the operation, the status is changed to
supported.
The meta surface has two new functions:
_cairo_meta_surface_replay_region()
_cairo_meta_surface_replay_and_create_regions()
During the analysis stage, the paginated surface replays the meta
surface using _cairo_meta_surface_replay_and_create_regions(). The
return status from each analyzed operation is saved in the meta
surface. The _cairo_meta_surface_replay_region() function allows only
operations from either the supported or unsupported region to be
replayed. This allows the paginated surface to replay only the
supported operations before emitting a fallback image for each
rectangle in the unsupported region.
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.
Previously we were ignoring ctm translation in scaled fonts when hashing, but
still storing it into the scaled font. Now we zero the translation components
when storing.
If width and height are 0 and pixman_traps is allocated on the heap,
it would leak. Fix by simply checking width and height prior to
allocating pixman_traps.
As noted in http://bugs.freedesktop.org/show_bug.cgi?id=12026 the error
path of _cairo_ft_unscaled_font_lock_face() failed to reset the
unscaled->lock_count before releasing the mutex and returning NULL.
