[cairo-commit] cairo ROADMAP, 1.4, 1.5 TODO, 1.48, 1.49 ChangeLog, 1.534, 1.535

[Owen Taylor]

Committed by: otaylor

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

Modified Files:
	ROADMAP TODO ChangeLog 
Log Message:
2005-04-28  Owen Taylor  <otaylor at redhat.com>

        * TODO, ROADMAP: Add a item about reworking cairo_format_t.


Index: ROADMAP
===================================================================
RCS file: /cvs/cairo/cairo/ROADMAP,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -d -r1.4 -r1.5
--- ROADMAP	26 Apr 2005 20:05:51 -0000	1.4
+++ ROADMAP	28 Apr 2005 20:41:00 -0000	1.5
@@ -64,6 +64,12 @@
 		    based on it
 	Status: cworth has sent API proposal to list
 
+ A8. cairo_format_t:
+        Difficulty: moderate. It's just going through and examining 
+                    each use of cairo_format_t, but there are a lot
+                    of them.
+        Status: not started, there is a rough plan in TODO
+
 Performance work
 ----------------
 ✓P1. Make pixel-aligned rectangle compositing fast

Index: TODO
===================================================================
RCS file: /cvs/cairo/cairo/TODO,v
retrieving revision 1.48
retrieving revision 1.49
diff -u -d -r1.48 -r1.49
--- TODO	26 Apr 2005 20:05:51 -0000	1.48
+++ TODO	28 Apr 2005 20:41:00 -0000	1.49
@@ -47,6 +47,38 @@
 
 	((src Op dest) In clip) Add (dest Out clip)
 
+* 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....)
+
 * Clean up the API in preparation for freezing and release.
 
 * Make a more interesting PS backend, (other than the current

Index: ChangeLog
===================================================================
RCS file: /cvs/cairo/cairo/ChangeLog,v
retrieving revision 1.534
retrieving revision 1.535
diff -u -d -r1.534 -r1.535
--- ChangeLog	28 Apr 2005 18:15:47 -0000	1.534
+++ ChangeLog	28 Apr 2005 20:41:00 -0000	1.535
@@ -1,3 +1,7 @@
+2005-04-28  Owen Taylor  <otaylor at redhat.com>
+
+	* TODO, ROADMAP: Add a item about reworking cairo_format_t.
+
 2005-04-28  Carl Worth  <cworth at cworth.org>
 
 	* test/.cvsignore: