[cairo-commit] [cairo-www] src/summerofcode

[Carl Worth]

 src/summerofcode/ideas.mdwn |   48 ++++++++++++++++++++++++++++++++++++--------
 1 file changed, 40 insertions(+), 8 deletions(-)

New commits:
commit 14caf1b332f1cbc5d47e2e0fa32e99f8566de97c
Author: Carl Worth <cworth at cworth.org>
Date:   Sun Mar 16 02:39:02 2008 +0100

    Add more details for some Summer-of-Code project ideas

diff --git a/src/summerofcode/ideas.mdwn b/src/summerofcode/ideas.mdwn
index 5f7141b..5db2bd2 100644
--- a/src/summerofcode/ideas.mdwn
+++ b/src/summerofcode/ideas.mdwn
@@ -3,25 +3,58 @@
 Library improvements
 ====================
 
-  * Implement a faster lookup-table-based rasterizer
-
-  * A significant improvement to pixman compositing code
+  * [Medium] Implement a faster lookup-table-based rasterizer
+
+    Cairo's software rasterization currently does a complete walk of a
+    regular 15x17 sampling grid for ever pixel in order to compute
+    coverage. This is quite slow. It would be great to have something
+    much faster.
+
+    With the recent change from 16 bits of sub-pixel precision to only
+    8 bits, (and perhaps even throwing some of those away), there's
+    perhaps something easy to do. One approach would be to generate a
+    lookup table based on all possible input and output positions of a
+    trapezoid edge to a pixel. Then rasterization can become nothing
+    more than 1 to 4 table lookups for each pixel.
+
+  * [Hard] A significant improvement to pixman compositing code
+
+    We know that we want something that is more dynamic than the
+    current approach of hand-writing optimized MMX/SSE2 functions for
+    special cases. We have a proof-of-concept of dynamic
+    code-generation for pixman in the jitblit library, but nothing
+    that's in a form suitable to ship, (due to unfinished parts of the
+    compilation framework that jitblit uses).
+
+    One possible approach would be to instead base a new framework on
+    [LLVM](http://llvm.org/) Søren also has some ideas about doing
+    something somewhat dynamic, but much less aggressive than the kind
+    of approach taken with jitblit.
 
   * Merge XLib and XCB backend similarly to what was done recently to PDF and PS
 
-  * Implement `cairo_stroke_to_path()`
+  * [Medium] Implement `cairo_stroke_to_path()`
+
+    This API function provides a new path that the outline that would
+    be formed by computing a stroke of the current path. The current
+    stroking algorithm does compute this path, but the path has some
+    undesired self-intersecting regions in it. These
+    self-intersections need to be detected and eliminated. The
+    intersection-finding code at the core of cairo's tessellation
+    implementation should provide all the primitive operations
+    necessary for this.
 
-  * Improve software polygon compositing by doing it in a
+  * [Hard] Improve software polygon compositing by doing it in a
     single scanline pass rather than tessellating, rasterizing, then
     compositing the entire polygon.
 
-  * Fix cairo so that a degenerate matrix draws nothing rather than
+  * [Medium] Fix cairo so that a degenerate matrix draws nothing rather than
     triggering an error state. That is: `cairo_scale (cr, 0, 0);` should
     not cause an error, (though maybe it shouldn't actually draw
     _nothing_ for painting an infinite source pattern---compute the
     average color for a surface-based source pattern perhaps?).
 
-  * Add color-space support to cairo.
+  * [Hard] Add appropriate color-management support to cairo.
 
   * [Medium] Add HDR image surface type to cairo/pixman (`CAIRO_FORMAT_ARGB64`).
 
@@ -53,4 +86,4 @@ Website improvements
 
    Ideally the rest of the wiki would be able to write cairo_create() and have
    that automatically link to the entry for cairo_create() in the reference manual.
-   A unified look and feel of the reference manual would be a plus.
\ No newline at end of file
+   A unified look and feel of the reference manual would be a plus.