[cairo-commit] cairo BUGS, 1.26, 1.27 ChangeLog, 1.843, 1.844 ROADMAP, 1.30, 1.31 TODO, 1.56, 1.57

Carl Worth commit at pdx.freedesktop.org
Sat Aug 6 16:57:17 PDT 2005


Committed by: cworth

Update of /cvs/cairo/cairo
In directory gabe:/tmp/cvs-serv9685

Modified Files:
	BUGS ChangeLog ROADMAP TODO 
Log Message:

2005-08-06  Carl Worth  <cworth at cworth.org>

        * BUGS: Remove several bugs that have been fixed.

        * ROADMAP: Slip group support off of the 1.0 roadmap. Update
        status of clipping work which otaylor is working on.

        * TODO: Update for progress on cairo_surface_mark_dirty
        (committed), non-antialiased rendering (patch), cairo_arc_to
        (patch), consistent error handling (committed), cairo_content_t
        (committed). Remove details for some completed items.

        * src/cairo-gstate.c (_cairo_gstate_set_font_face): Don't crash if
        font_face is NULL, (this is a documented mechanism for returning
        to the default font_face).


Index: BUGS
===================================================================
RCS file: /cvs/cairo/cairo/BUGS,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -d -r1.26 -r1.27
--- BUGS	18 Jul 2005 05:15:57 -0000	1.26
+++ BUGS	6 Aug 2005 23:57:14 -0000	1.27
@@ -5,40 +5,11 @@
 
 --
 
-cairo_show_surface fails when given a non-default CTM, see the
-show_surface.cairo snippet in:
-
-	From: Per Bjornsson <perbj at stanford.edu>
-	To: Cairo mailing list <cairo at cairographics.org>
-	Date: Wed, 09 Feb 2005 20:05:35 -0800
-	Message-Id: <1108008335.5349.46.camel at 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).
 

Index: ChangeLog
===================================================================
RCS file: /cvs/cairo/cairo/ChangeLog,v
retrieving revision 1.843
retrieving revision 1.844
diff -u -d -r1.843 -r1.844
--- ChangeLog	6 Aug 2005 23:38:33 -0000	1.843
+++ ChangeLog	6 Aug 2005 23:57:14 -0000	1.844
@@ -1,5 +1,21 @@
 2005-08-06  Carl Worth  <cworth at cworth.org>
 
+	* BUGS: Remove several bugs that have been fixed.
+	
+	* ROADMAP: Slip group support off of the 1.0 roadmap. Update
+	status of clipping work which otaylor is working on.
+	
+	* TODO: Update for progress on cairo_surface_mark_dirty
+	(committed), non-antialiased rendering (patch), cairo_arc_to
+	(patch), consistent error handling (committed), cairo_content_t
+	(committed). Remove details for some completed items.
+
+	* src/cairo-gstate.c (_cairo_gstate_set_font_face): Don't crash if
+	font_face is NULL, (this is a documented mechanism for returning
+	to the default font_face).
+
+2005-08-06  Carl Worth  <cworth at cworth.org>
+
 	* src/cairo.c (cairo_get_font_face): Fix to return
 	&_cairo_font_face_nil instead of NULL on error.
 

Index: ROADMAP
===================================================================
RCS file: /cvs/cairo/cairo/ROADMAP,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -d -r1.30 -r1.31
--- ROADMAP	1 Aug 2005 18:45:42 -0000	1.30
+++ ROADMAP	6 Aug 2005 23:57:14 -0000	1.31
@@ -4,7 +4,7 @@
 -------------------
  I1. Fix clipping to be sane
 	Dificulty: moderate
-	Status: cworth has started looking at this
+	Status: otalyor is working on this.
 
  I2. Real PostScript/PDF fallbacks (cairo_meta_surface_t)
 	Difficulty: hard
@@ -32,15 +32,6 @@
 
 API additions (more detail in TODO file)
 ----------------------------------------
- A3. Add cairo_begin/end/get_group
-	Difficulty: easy to hard (depending on how sophisticated an
-	            implementation is acceptable, and whether the
-		    cairo_meta_surface_t mentioned in [I2] is done)
-
-	Status: cworth has a posted a preliminary patch, and keithp,
-		krh, and otaylor answered all the tough questions it
-		raised. There's not much work left to finish this one.
-
 ✓A7. cairo_surface_mark_dirty and cairo_surface_flush
 	Difficulty: trivial to add API, moderate to actually optimize
 		    based on it
@@ -60,3 +51,14 @@
 
  P3. Glyph measurement needs to be sped up.
 	Status: Now planned as part of I4 above ("cache lock deadlock")
+
+Things that have been dropped from the 1.0 roadmap
+==================================================
+ A3. Add cairo_begin/end/get_group
+	Difficulty: easy to hard (depending on how sophisticated an
+	            implementation is acceptable, and whether the
+		    cairo_meta_surface_t mentioned in [I2] is done)
+
+	Status: cworth has a posted a preliminary patch, and keithp,
+		krh, and otaylor answered all the tough questions it
+		raised. There's not much work left to finish this one.

Index: TODO
===================================================================
RCS file: /cvs/cairo/cairo/TODO,v
retrieving revision 1.56
retrieving revision 1.57
diff -u -d -r1.56 -r1.57
--- TODO	17 Jun 2005 17:48:47 -0000	1.56
+++ TODO	6 Aug 2005 23:57:14 -0000	1.57
@@ -10,12 +10,12 @@
 Backwards compatible (API additions only)
 -----------------------------------------
 	cairo_begin_group, cairo_end_group, cairo_get_group
-	cairo_surface_mark_dirty (see below for details)
-	Add support for non-antialiased rendering. API ?
+PDR C	cairo_surface_mark_dirty (see below for details)
+PDR	Add support for non-antialiased rendering. API ?
 	Add CAIRO_FILL_RULE_INVERSE_WINDING and CAIRO_FILL_RULE_INVERSE_EVEN_ODD
 	Add cairo_text_glyphs (see below for details)
 	Add support for programmatic patterns, (ie. arbitrary gradients)
-	Add cairo_arc_to.
+P	Add cairo_arc_to.
 	Add support for custom caps (see below for details)
 	Add support for getting at image data from image surface
 	Add CAIRO_STATUS_DESTROYED
@@ -25,29 +25,12 @@
 -------------------------------------------------
 PDR C	cairo_surface_finish, cairo_surface_flush
 PDR C	A hidden offset for the xlib backend
-P	Consistent error handling for all objects
-	Split cairo_format_t (see below for details)
+PDR C	Consistent error handling for all objects
+PDRTC	Split cairo_format_t (see below for details)
 P---C	Remove cairo_status_string in favor of cairo_status_to_string
 
 Details on some of the above changes
 ------------------------------------
-* cairo_surface_mark_dirty
-
-  One question is what the function should accept. A single
-  device-space rectangle seems like a consistent approach. That would
-  allow us to avoid needing backend-specific functions with
-  backend-specific region datatypes, (cf. clipping support)
-
-  In order to get the intended efficiency benefits, we'll need to make
-  two changes:
-
-	1) In the fallback code, never fetch any data from the clean
-           region.
-
-	2) Mark clean any region drawn with device-pixel aligned
-           rectangles, (cairo_paint with no clip is the most iportant
-           one here).
-
 * cairo_text_glyphs:
 
 	It would function as a sort of bridge between the toy and the
@@ -78,51 +61,13 @@
   current path. We may also need to provide the coordinates of the
   faces of every dash as well.
 
-* split cairo_format_t into two things:
-
-   - An enumeration that determines the "capabilities" of a surface - 
-     A vs. ARGB. vs. RGB
-   - An enumeration that determines a specific in-memory representation
-     of data. (A1/A8/ARGB32/etc.. Could be extensible to things like
-     RGBA32_BYTES_NONPREMULTIPLIED. Some consistent naming convention would 
-     be be good.)
-
-  One issue here is that some interfaces, like cairo_surface_create_similar()
-  might be useful with either one. We might want to create an A1 surface
-  compatible with the backend (are there examples other than A1? Should 
-  bilevel just be another "capability"?), or we might want to just create
-  an alpha surface without caring about the depth.
-
-  If we want to support this, we could do something like:
-
-   typedef enum cairo_pixel_format_t {
-     CAIRO_PIXEL_FORMAT_A8 = CAIRO_FORMAT_ALPHA,
-     CAIRO_PIXEL_FORMAT_RGB24 = CAIRO_FORMAT_RGB,
-     CAIRO_PIXEL_FORMAT_A1,
-   };
-
-  To allow passing either in. 
-
-  (I don't particularly like this idea for create_similar() because then you 
-  aren't really saying ALPHA-dont-care, you are saying ALPHA-8. I think it 
-  would be better to have a separate path for create_similar_with_pixel_format() 
-  if we need that. But it might be useful for cairo_image_surface_create() ... 
-  people are  going to screw up and pass CAIRO_FORMAT_RGB into that, and if it
-  "just worked" that would save people trouble....)
-
 Changes that do not affect the public API
 =========================================
-* Clean up the cache code a bit, (there is at least one redundant
-  level of cacheing, and there are some minor style issues).
-
 * Fix clipping to work for all operators. The equation we have come up
   with is:
 
 	((src Op dest) In clip) Add (dest Out clip)
 
-* Make a more interesting PS backend, (other than the current
-  "giant-image for every page" approach).
-
 * Change stroke code to go through one giant polygon. This will fix
   problems with stroking self-intersecting paths.
 




More information about the cairo-commit mailing list