Make sure that all operations are correct (the operations chosen
are listed in cairo-win32-surface.c); in particular, deal with the extra
byte present in FORMAT_RGB24 surfaces correctly.
Also adds support for calling StretchDIBits to draw RGB24
cairo_image_surfaces directly.
It turns out that all of the callers want a box anyway, so this
simplfies the code in addition to being more honest to the name.
(For those new to the convention, a "box" is an (x1,y2),(x2,y2)
pair while a "rectangle" is an (x,y),(width,height) pair.)
This broke with the clone_similar optimization in
8d7a02ed58 The optimization added an
interest rectangle to clone_similar, but with a repeating source
pattern, the interest rectangle might not intersect the extents of the
surface at all.
The test suite caught this with the trap-clip case.
The fix here is to clone the entire surface if the pattern has an
extend mode of REPEAT.
This fixes a huge performance bug (entire image was being pushed to X
server in order to copy a tiny piece of it). I see up to 50x improvement
from subimage_copy (which was designed to expose this problem) but also
a 5x improvement in some text performance cases.
xlib-rgba subimage_copy-512 3.93 2.46% -> 0.07 2.71%: 52.91x faster
███████████████████████████████████████████████████▉
xlib-rgb subimage_copy-512 4.03 1.97% -> 0.09 2.61%: 44.74x faster
███████████████████████████████████████████▊
xlib-rgba subimage_copy-256 1.02 2.25% -> 0.07 0.56%: 14.42x faster
█████████████▍
xlib-rgba text_image_rgb_over-256 63.21 1.53% -> 11.87 2.17%: 5.33x faster
████▍
xlib-rgba text_image_rgba_over-256 62.31 0.72% -> 11.87 2.82%: 5.25x faster
████▎
xlib-rgba text_image_rgba_source-256 67.97 0.85% -> 16.48 2.23%: 4.13x faster
███▏
xlib-rgba text_image_rgb_source-256 68.82 0.55% -> 16.93 2.10%: 4.07x faster
███▏
xlib-rgba subimage_copy-128 0.19 1.72% -> 0.06 0.85%: 3.10x faster
██▏
This doesn't actually fix the AMD64 link failure, but it does make the
foo/EXT_foo/INT_foo symbol names generated by the slim_hidden_proto()
and slim_hidden_def() macros consistent in the face of the meddling of
pixman-remap.h.
Signed-off-by: Nicholas Miell <nmiell@gmail.com>
There are still some problems in the resulting output:
PDF: Rotated font ends up being blurry in final PNG (not too important)
PS and SVG: There's an incorrect offset being applied somewhere.
This approach to fixing the bug is valid since there is code in pixman
for rendering to BGR images, (which is why cairo 1.0 worked with BGR X
servers for example). But, since we don't want to advertise additional
image formats we implement this through a new cairo_internal_format_t.
This is rather fragile since we don't want to leak any internal formats
nor do we ever want an internal format to be used somewhere a real
format is expected, (and trigger a CAIRO_FORMAT_VALID assertion failure).
More comments than code are added here to help compensate for the
fragility and to give some guidance in fixing this mess in a better way
in the future.
In addition to helping us preserve a sharp line between which symbols are
part of the public API and which are private parts of the implementation,
this can also help mozilla avoid clashes between its modified, internal
copy of cairo and the system version of cairo. See the mozilla bug here:
https://bugzilla.mozilla.org/show_bug.cgi?id=341874
Add a load_truetype_table function to cairo_scaled_font_backend_t and
use it to load the truetype sfnt tables. Implement this with freetype
for the freetype font backend and use GetFontData for win32. Atsui
remains unimplemented, and still falls back to type3 fonts.
New internal function _cairo_surface_set_font_options is used to set them.
cairo_surface_create_similar propagates the font options of the other
surface into the newly created surface. Fixes bugs with font options in
fallback images and bug 4106.
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.
This uses a technique devised by Sean Anderson, July 13, 2001 as found
at http://graphics.stanford.edu/~seander/bithacks.html#ReverseByteWith32Bits
This technique uses 3 multiplies rather than just shifts and masks, but
performance seems comparable to the old approach, (but more significantly,
the new approach is easier to implement as a macro, and I plan to start
using this bit-swapping elsewhere very soon).
This allows graceful recovery when first requesting a path from a font
that only supports bitmapped glyph. The changed return type is also
pushed down into the scaled_glyph_init function of the
cairo_scaled_font backend.
Most internal cairo types are transparent within cairo and have init and fini
functions to intialize and finialize them in place. This way they can be
easily be embedded in other structs or derived from. Initially, the
cairo_output_stream_t type was proposed as a publically visible type and
thus kept opaque. However, now it's only used internally and derived from
in a number of places so let's make it an embeddable type for consistency
and ease of use.
The patch keeps _cairo_output_stream_create() and _cairo_output_stream_close()
around for (internal) backwards compatibility by deriving a
cairo_output_stream_with_closure_t stream type.
The patch also moves all cairo_output_stream_t functions out of cairoint.h
and into new file cairo-output-stream-private.h, thus chipping away at the
monolithic cairoint.h.
Add new, private _cairo_surface_set_device_scale for getting at the
scaling components of device_transform. Use this in paginated surface
when replaying to an image surface. The fallback-resolution test now
clearly shows that image fallback resolution can be controlled by the
user. Hurrah!
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.
This just provides the mechanics for storing the value and removing the old
function calls. The new value is still not used anywhere (though nor where
the old values), so there should be no functional change (other than forcing
any programs calling the old API to be updated).
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).
