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 To: Cairo mailing list 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 * * 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.