mirror of
https://gitlab.freedesktop.org/cairo/cairo.git
synced 2025-12-25 11:50:16 +01:00
161 lines
4.4 KiB
Text
161 lines
4.4 KiB
Text
cairo-xlib-surface needs to do the Xlib register extension hack so
|
|
that it can listen for a Display close event. When it gets that, it
|
|
needs to run through its caches and eliminate anything associated with
|
|
that display.
|
|
|
|
--
|
|
|
|
cairo_show_surface fails when given a non-default CTM, see the
|
|
show_surface.cairo snippet in:
|
|
|
|
From: Per Bjornsson <perbj@stanford.edu>
|
|
To: Cairo mailing list <cairo@cairographics.org>
|
|
Date: Wed, 09 Feb 2005 20:05:35 -0800
|
|
Message-Id: <1108008335.5349.46.camel@localhost.localdomain>
|
|
Subject: [cairo] How is cairo_show_surface supposed to work?
|
|
|
|
--
|
|
|
|
cairo_image_surface_create should return a blank image
|
|
(eg. transparent black) instead of an image with random data in it.
|
|
|
|
--
|
|
|
|
cairo_surface_create_for_image is claiming ownership of the user's data.
|
|
|
|
--
|
|
|
|
cairo_font_set_transform should be renamed cairo_font_set_matrix
|
|
cairo_font_current_transform should be renamed cairo_font_get_matrix
|
|
|
|
--
|
|
|
|
Alexis Georges reports a segfault on AMD64 with a simple program,
|
|
(that works in a 32bit chroot).
|
|
|
|
--
|
|
|
|
The caches need to have some locking (see: [cairo] Static caches and thread-safety)
|
|
|
|
--
|
|
|
|
Scaling of surface patterns is all broken, (try xsvg
|
|
gradPatt-pattern-BE-07.svg and zoom in and out).
|
|
|
|
--
|
|
|
|
centi_unfinished.svg has big black portions when drawn with svg2png,
|
|
(but not when drawn with xsvg).
|
|
|
|
--
|
|
|
|
The caches need to be invalidated at font destruction time.
|
|
|
|
--
|
|
|
|
cairo_clip is really slow, (with at least the Xlib and image
|
|
backends). An accelerated implementation of the IN operator would
|
|
probably help a lot here.
|
|
|
|
--
|
|
|
|
Splines are not dashed.
|
|
|
|
--
|
|
|
|
The polygon tessellation routine has problems. It appears that the
|
|
following paper has the right answers:
|
|
|
|
http://cm.bell-labs.com/cm/cs/doc/93/2-27.ps.gz
|
|
|
|
[Hobby93c] John D. Hobby, Practical Segment Intersection with
|
|
Finite Precision Output, Computation Geometry Theory and
|
|
Applications, 13(4), 1999.
|
|
|
|
Recent improvements to make the intersection code more robust (using
|
|
128-bit arithmetic where needed), have exposed some of the weakness in
|
|
the current tessellation implementation. So, for now, filling some
|
|
polygons will cause "leaking" until we implement Hobby's algorithm.
|
|
|
|
--
|
|
|
|
Stroking a self-intersecting path generates the wrong answer, (in
|
|
mostly subtle ways). The fix is to tessellate a giant polygon for the
|
|
entire stroke outline rather than incrementally generating trapezoids.
|
|
|
|
--
|
|
|
|
Cairo is crashing Xnest with the following message:
|
|
|
|
X Error of failed request: BadMatch (invalid parameter attributes)
|
|
Major opcode of failed request: 72 (X_PutImage)
|
|
Serial number of failed request: 28
|
|
Current serial number in output stream: 29
|
|
|
|
confirmed on a quite default install of debian unstable.
|
|
|
|
--
|
|
|
|
cairo_scale_font modifies objects that the user expects to not change. For example:
|
|
|
|
cairo_font_t *font;
|
|
|
|
cairo_select_font (cr, "fixed", 0, 0);
|
|
font = cairo_current_font (cr);
|
|
cairo_scale_font (cr, 10);
|
|
cairo_show_text (cr, "all is good");
|
|
cairo_set_font (cr, font);
|
|
cairo_scale_font (cr, 10);
|
|
cairo_show_text (cr, "WAY TOO BIG!!);
|
|
|
|
We could fix this by not storing the scale in the font object. Or
|
|
maybe we could just force the size to its default after set_font. Need
|
|
to think about this in more detail.
|
|
|
|
--
|
|
|
|
cairo_show_text is not updating the current point by the string's advance values.
|
|
|
|
--
|
|
|
|
Caps are added only to the last subpath in a complex path.
|
|
|
|
--
|
|
|
|
ref_counts will go negative if destroy is called with ref_count ==
|
|
0. We noticed this in cairo_surface.c but it likely happens in several
|
|
places.
|
|
|
|
--
|
|
|
|
Patterns are broken in various ways. The SVG test case demonstrates
|
|
some regressions, so something has changed in cairo. Also,
|
|
transformation plus repeat doesn't work in either Xrender or
|
|
libpixman, (nor in glitz?).
|
|
|
|
--
|
|
|
|
font-size="0" in an SVG file does very bad things.
|
|
|
|
--
|
|
|
|
move_to_show_surface (see cairo/test):
|
|
|
|
* 2004-10-25 Carl Worth <cworth@cworth.org>
|
|
*
|
|
* It looks like cairo_show_surface has no effect if it follows a
|
|
* call to cairo_move_to to any coordinate other than 0,0. A little
|
|
* bit of poking around suggests this isn't a regression, (at least
|
|
* not since the last pixman snapshot).
|
|
|
|
--
|
|
|
|
cairo falls over with XFree86 4.2 (probably braindead depth handling
|
|
somewhere).
|
|
|
|
--
|
|
|
|
The caches abort when asked for a too-large item, (should be possible
|
|
to trigger by asking for a giant font, "cairo_scale_font (cr, 2000)"
|
|
perhaps). Even if the caches don't want to hold them, we need to be
|
|
able to allocate these objects.
|