[cairo-commit] cairo ChangeLog,1.639,1.640 TODO,1.52,1.53
Carl Worth
commit at pdx.freedesktop.org
Fri Jun 10 13:19:47 PDT 2005
Committed by: cworth
Update of /cvs/cairo/cairo
In directory gabe:/tmp/cvs-serv32699
Modified Files:
ChangeLog TODO
Log Message:
* TODO: Big cleanup to remove finished items. Also, split the file
up to separate TODO items that affect the API from items that do
not.
Index: ChangeLog
===================================================================
RCS file: /cvs/cairo/cairo/ChangeLog,v
retrieving revision 1.639
retrieving revision 1.640
diff -u -d -r1.639 -r1.640
--- ChangeLog 10 Jun 2005 19:46:49 -0000 1.639
+++ ChangeLog 10 Jun 2005 20:19:45 -0000 1.640
@@ -1,5 +1,11 @@
2005-06-10 Carl Worth <cworth at cworth.org>
-
+
+ * TODO: Big cleanup to remove finished items. Also, split the file
+ up to separate TODO items that affect the API from items that do
+ not.
+
+2005-06-10 Carl Worth <cworth at cworth.org>
+
Originally: 2005-06-09 Carl Worth <cworth at cworth.org>
* src/cairo-pdf-surface.c: (_cairo_pdf_surface_show_page):
Index: TODO
===================================================================
RCS file: /cvs/cairo/cairo/TODO,v
retrieving revision 1.52
retrieving revision 1.53
diff -u -d -r1.52 -r1.53
--- TODO 22 May 2005 16:08:23 -0000 1.52
+++ TODO 10 Jun 2005 20:19:45 -0000 1.53
@@ -1,56 +1,82 @@
-API Shakeup planning
---------------------
+Changes that are expected to impact the public API
+==================================================
+
Patch submitted to mailing list?
/ Documentation included in patch?
|/ Review of patch completed?
||/ Test case included?
|||/ Committed.
||||/
-New functionality (more-or-less)
---------------------------------
+Backwards compatible (API additions only)
+-----------------------------------------
cairo_begin_group, cairo_end_group, cairo_get_group
- cairo_<device>_surface_mark_dirty
-P Consistent error handling for all objects
+ cairo_surface_mark_dirty (see below for details)
+ 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.
+ Add support for custom caps (see below for details)
+ Add support for getting at image data from image surface
-Somewhat backwards-compatible changes
------------------------------------
-PDRTC user data (was Re: [cairo] Patch improving fallbacks)
-PDRTC setters and getters
-PDRTC cairo_output_stream_t and cairo_surface_finish()
-PDRTC cairo_current_path -> cairo_copy_path_data
+Backwards incompatible (API deletions or changes)
+-------------------------------------------------
PDR C cairo_surface_finish, cairo_surface_flush
-PDRTC Abbreviation hunt: cairo_init_clip and cairo_concat_matrix
-PDRTC Renaming the terms of the rendering equation
-PDRTC default matrix
-PDRTC cairo_paint
-PDRTC Making set_source consistent
-PDRTC cairo_stroke_path -> cairo_stroke_to_path
-PDRTC cairo_current_matrix
-PDRTC cairo_mask
-PDRTC cairo_fill_preserve, cairo_stroke_preserve, cairo_clip_preserve
PDR C A hidden offset for the xlib backend
+P Consistent error handling for all objects
+ Split cairo_format_t (see below for details)
+ Remove cairo_status_string in favor of cairo_status_to_string ?
-Backwards incompatible
-----------------------
-PDRTC Simplifying the operator set
-PDRTC cairo_create and eliminating cairo_set_target_surface
-PDRTC Eliminating cairo_copy
-PDRTC Eliminating cairo_surface_set_repeat/matrix/filter
-PDRTC Eliminating cairo_show_surface
+Details on some of the above changes
+------------------------------------
+* cairo_surface_mark_dirty
-* Add support for non-antialiased rendering. API ?
+ 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)
-* Clean up the cache code a bit, (there is at least one redundant
- level of cacheing, and there are some minor style issues).
+ In order to get the intended efficiency benefits, we'll need to make
+ two changes:
-* Add CAIRO_FILL_RULE_INVERSE_WINDING and CAIRO_FILL_RULE_INVERSE_EVEN_ODD
+ 1) In the fallback code, never fetch any data from the clean
+ region.
-* Fix clipping to work for all operators. The equation we have come up
- with is:
+ 2) Mark clean any region drawn with device-pixel aligned
+ rectangles, (cairo_paint with no clip is the most iportant
+ one here).
- ((src Op dest) In clip) Add (dest Out clip)
+* cairo_text_glyphs:
-* Split cairo_format_t into two things:
+ It would function as a sort of bridge between the toy and the
+ real text APIs:
+
+ > void
+ > cairo_text_glyphs (cairo_t *cr, const unsigned char *utf8,
+ > cairo_glyph_t *glyphs, int *num_glyphs);
+ >
+ > with num_glyphs as an input-output parameter. The behavior of this
+ > function would be such that calling:
+ >
+ > cairo_text_glyphs (cr, string, glyphs, &num_glyphs);
+ > cairo_show_glyphs (cr, glyphs, num_glyphs);
+ >
+ > would be equivalent too:
+ >
+ > cairo_show_text (cr, string);
+ >
+ > as long as the original size of glyphs/num_glyphs was large
+ > enough.
+
+* support for custom caps:
+
+ It would be nice if the user had a mechanism to reliably draw custom
+ caps. One approach here would be to provide the coordinates of the
+ butt cap faces so that the user can append seamless caps to the
+ 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
@@ -82,92 +108,35 @@
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.
+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).
-* Make a more interesting PS backend, (other than the current
-"giant-image for every page" approach).
+* Fix clipping to work for all operators. The equation we have come up
+ with is:
-* Figure out what to do with DPI for image/png backends.
+ ((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.
+ problems with stroking self-intersecting paths.
* Re-work the backend clipping interface to use geometry rather than
-images.
+ images, (krh has posted a patch for this)
* Fix the intersection problem, (see reference to Hobby's paper
-mentioned in cairo_traps.c).
-
-* Add a new cairo_text_glyphs function (a sort of bridge between the
-toy and the real text API):
-
- > void
- > cairo_text_glyphs (cairo_t *cr, const unsigned char *utf8,
- > cairo_glyph_t *glyphs, int *num_glyphs);
- >
- > with num_glyphs as an input-output parameter. The behavior of this
- > function would be such that calling:
- >
- > cairo_text_glyphs (cr, string, glyphs, &num_glyphs);
- > cairo_show_glyphs (cr, glyphs, num_glyphs);
- >
- > would be equivalent too:
- >
- > cairo_show_text (cr, string);
- >
- > as long as the original size of glyphs/num_glyphs was large
- > enough.
+ mentioned in cairo_traps.c).
* Implement dashing for cairo_curve_to.
-* Implement support for programmatic patterns, (ie. figure out how to
-do gradients the Right Way).
-
-* Implement cairo_arc_to.
-
* Stroking closed, degenerate paths should still draw caps. Round
caps are easy; square should probably draw an axis-aligned square.
-* It would be nice if the user had a mechanism to reliably draw custom
- caps. One approach here would be to provide the coordinates of the
- butt cap faces so that the user can append seamless caps to the
- current path. We may also need to provide the coordinates of the
- faces of every dash as well.
-
* Should add geometry pruning as appropriate.
-* We need a way to get at the image data after something
- like cairo_surface_create_similar with the image backend.
-
-* Three suggestions from Owen that will help GTK+ performance:
-
- - The ability have an additional rectangle-list clip in the
- Xlib surface. Frequently during an expose event, GTK+ is
- drawing L shaped areas
-
- XXXXXX
- X.....
- X.....
-
- And passing the real clip to the server is going to save
- a lot of pixel operations that will be thrown away.
-
- - The ability to pass in a width/height to cairo_xlib_surface_create()
- to avoid a round-trip. (Round-trips are bad to the point where
- querying the the server is something you don't want to do in
- production software)
-
- - More of a future thing, the ability to hint to to cairo that
- the contents of the Xlib surface passed to
- cairo_xlib_surface_create() are a solid fill ... this is
- very much the normal case for GTK+ usage and allows for
- big optimization in the no-RENDER case.
- (see http://mail.gnome.org/archives/gtk-devel-list/2003-March/msg00045.html
-
* Verification, profiling, optimization.
centi_unfinished.svg may provide a good test case.
-
-* Implement copy-on-write regions in pixman as a more complete
- solution than the BAD_NESTING stuff to Owen's "Clip region problems"
- thread.
More information about the cairo-commit
mailing list