mirror of
https://gitlab.freedesktop.org/cairo/cairo.git
synced 2026-01-08 11:50:26 +01:00
31534f264c
Remove __internal_linkage macro from all functions returning pointers to shut up warning from gcc 3.4.
122 lines
3.5 KiB
Text
122 lines
3.5 KiB
Text
As of gcc 3.4, all uses of the __internal_linkage macro on
|
|
functions returning pointers to structured types are causing a
|
|
warning of the form:
|
|
|
|
cairoint.h:406: warning: `__visibility__' attribute ignored on non-class types
|
|
|
|
I'm commenting these out to shut up the compiler, and tagging each
|
|
case with "XXX-NON-CLASS:". We should determine if these uses should be
|
|
removed completely or if they can be fixed in some way.
|
|
|
|
--
|
|
|
|
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.
|