[cairo-commit] [cairo-www] src/summerofcode src/summerofcode.mdwn src/todo.mdwn
Bryce Harrington
bryce at freedesktop.org
Thu Dec 15 02:39:08 UTC 2016
src/summerofcode.mdwn | 37 ---------
src/summerofcode/ideas.mdwn | 179 --------------------------------------------
src/todo.mdwn | 141 ++++++++++++++++++++++++++++++++++
3 files changed, 141 insertions(+), 216 deletions(-)
New commits:
commit 2c2f4e42c38188bf20afc769241e5a827bfc1997
Author: Bryce Harrington <bryce at bryceharrington.org>
Date: Wed Dec 14 18:36:25 2016 -0800
todo: Move remaining ideas from GSoC 2008 to the main todo list
Many of the project ideas from GSoC 2008 look like they are still
relevant tasks, and were given reasonably detailed definition. So
consolidate them into the master todo list for easier finding.
Cairo has not participated in GSoC since 2008, so there doesn't seem to
be a need to keep this page active. Most of the info is obsolete; if we
need it for historical reference some day, then it can be fished out of
VCS.
diff --git a/src/summerofcode.mdwn b/src/summerofcode.mdwn
deleted file mode 100644
index b15b1a5..0000000
--- a/src/summerofcode.mdwn
+++ /dev/null
@@ -1,37 +0,0 @@
-[[!meta title="Cairo participates in Google Summer of Code 2008"]]
-
-Welcome, students!
-
-The cairo graphics project is participating in [Google Summer of Code
-2008](http://code.google.com/soc/2008/). This is a fantastic
-opportunity for students to gain experience with the free-software
-community, work closely with experts, and also make a valuable
-contribution to a significant project. More than that, working with the
-cairo graphics library and community is a lot of fun! (And Google
-even pays the student a little bit.)
-
-Interested students should review [Google's
-overview](http://code.google.com/soc/2008/) of the program and also
-the [cairo project's ideas](http://cairographics.org/summerofcode/ideas/).
-Each idea in this list contains a short description of what the
-project would consist of, and also a difficulty rating (Easy, Medium,
-or Hard), so that students can better estimate their ability to
-complete the project.
-
-Any student that sees an interesting project idea there should then
-subscribe to the [cairo at cairographics.org mailing
-list](http://cairographics.org/lists/) and send an email off stating
-the project of interest. There on the list, the student can start to
-interact with potential mentors and learn more details about what the
-project will require.
-
-Finally, between March 24 and March 31, (see [Google's
-timeline](http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_timeline)
-for the exact cutoff dates/times) students will submit applications to
-the Summer of Code program. And then the real fun starts as mentors
-and students work together over the (northern hemisphere) summer to
-make cairo more excellent than ever.
-
-We're pleased that you're interested in the cairo graphics
-library. And we hope that you enjoy playing with and improving this
-code. Have fun with cairo!
diff --git a/src/summerofcode/ideas.mdwn b/src/summerofcode/ideas.mdwn
deleted file mode 100644
index 4284597..0000000
--- a/src/summerofcode/ideas.mdwn
+++ /dev/null
@@ -1,179 +0,0 @@
-[[!meta title="Cairo's Summer of Code Pool of Ideas"]]
-
-The cairo project is glad to be participating in [Google Summer of
-Code 2008](http://code.google.com/soc/2008/). See the [cairo
-announcement](http://cairographics.org/news/2008/03/17/cairo_summer_of_code/)
-for an overview of the process to be followed by students, then come
-back here for a list of potential project ideas.
-
-Why cairo is cool
-=================
-
-Cairo has a great community of users and developers. We use a single
-mailing list for both user questions and development discussions.
-This has proved to be a very effective way of helping users become
-developers gradually. It all starts by submitting that small first
-patch. The same thing applies to our IRC channel. Please feel free to
-join and watch for a few days, to get the hang of it. We never say
-"this is not the right list/channel for this question/discussion".
-Mailing list and IRC information can be found on the [cairo contact
-page](http://cairographics.org/contact/).
-
-Overview of the library
-=======================
-
-Cairo is a library written in the C programming language. Its main
-external dependency is a library called pixman that does the software
-rendering for cairo. Most of the ideas below do not touch on Pixman
-though. See [cairo download](http://cairographics.org/download/) for
-instructions on how to obtain the cairo source code.
-
-Cairo has a very clean code base that is a pleasure to read. We
-believe that source code should be written with a primary goal to make
-it easy to be read by humans. The file names are very clean and
-instantly give an easily understandable map of the code base. For
-example, the cairo xlib surface backend is implemented in
-src/cairo-xlib-surface.c. All the other xlib-specific code is under
-src/cairo-xlib-*.c names too. The code itself is fairly well
-documented with comments and documentation blocks for all public
-symbols. The best way to start seeing how things work, after you have
-checked the [documentation](http://cairographics.org/documentation/)
-and know how to _use_ cairo, is to start skimming through src/cairo.c
-and checking out other source files from there.
-
-Summer of Code Project Ideas
-============================
-
-Each idea below is given a difficulty estimate, (Easy, Medium, or
-Hard), determined by one of the potential mentors. Please use these
-ratings to help choose an appropriate project. If a project
-description uses terms you've never heard of and is also rated Hard,
-then you can know that that's a project that will provide plenty of
-learning experiences for you. If a project is rated as Easy, then
-maybe it won't keep your interest and give you the intellectual
-challenge you're looking for.
-
- * [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.
-
- * [Medium] Merge XLib and XCB backend similarly to what was done recently to PDF and PS
-
- Currently there are separate XLib and XCB cairo surface backends.
- The problem is, the XCB backend is not maintained and does not get
- the same treatment (bug fixes, improvements, ...) that the XLib
- backend does. The two also duplicate a lot of code. The idea is to merge
- the duplicate code, possibly using a similar approach used to make
- the Postscript and PDF backends share code, namely, cairo-pdf-operators.c.
-
- * [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.
-
- * [Hard] Improve software polygon compositing by doing it in a
- single scanline pass rather than tessellating, rasterizing, then
- compositing the entire polygon.
-
- * [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?).
-
- * [Hard] Add appropriate color-management support to cairo.
-
- Cairo needs the ability to allow for color management. By this project it
- will become possible to work in different color spaces, convert
- automatically to blend different content and tag graphics objects to tell
- backends about the color spaces involved. The color space information
- will follow the ICC standard.
-
- In this project you will learn about the constraints at different OS'es and handle API abstraction.
- During the programming work you will design and implement the
- corresponding means covering frontside API's and backend specific code due
- to file formats and other specific requirements.
- A small application, showing the new capabilities, will help in spotting
- problems and can later be used for demonstrations.
- A unit test and documentation is required for maintainablility and further
- easy deployment.
-
- Some relevant threads from various mailing lists:
-
- - [Color, Cairo and Cups](http://lists.freedesktop.org/archives/cairo/2006-March/006518.html)
- - [PDF, CMYK and cairo](http://www.nabble.com/PDF,-CMYK-and-cairo-td15636763.html)
- - [Creating CMYK and spot colors using Postscript backend](http://nashi.altmuehlnet.de/pipermail/scribus/2007-May/023894.html)
- - [Tessellating complex figures with Render](http://marc.info/?l=xfree-render&m=102121486826819&w=2) contains a subthread on color spaces.
-
- Ideally this should also incorporate HDR as discussed in the next suggestion.
-
- * [Medium] Add HDR image surface type to cairo/pixman (`CAIRO_FORMAT_ARGB64`).
-
- The new image format will implement the [scRGB](http://en.wikipedia.org/wiki/Scrgb) colorspace.
- This involves either extending the pixman library to support the new format, or write code for
- Porter-Duff compositing on the new format and make cairo use them for ARGB64.
-
- Conversions between the 16-bit floats used by colour spaces such as scRGB and 32-bit floats
- should use the algorithms explained in Jeroen van der Zijp’s [Fast Half Float Conversions](ftp://www.fox-toolkit.org/pub/fasthalffloatconversion.pdf).
-
- * [Easy] Add a performance/conformance suite for the vector backends.
-
- One goal would be to aim to make the output file size competitive to other generators (e.g. gs).
- Conformance could be checked by running the test output through various validators:
- [SVG validator](http://wiki.svg.org/SVG_Validator).
-
- * [Hard] Add support for PDF/PostScript Type 6 (Coons patch mesh) and/or Type 7 (Tensor-Product patch mesh) shading functions to the image backend
-
- The Type 6 shading is a special case of the Type 7 shading so only implementing Type 7 may be all that is required.
-
- One possible solution would be to create a triangle mesh (similar to Type 4 shadings) from the Type 7 patch mesh and shade the triangles using Gouraud shading.
-
- The [Poppler](http://poppler.freedesktop.org/) source may be used to get an idea how Poppler renders these gradients . However the approach Poppler uses of recursively breaking each patch into smaller patches then filling the tiny patches with a solid color is not appropriate for cairo due to the visible seams between patches due to antialising.
-
- The algorithm for Gouraud shading is in many books on computer graphics.
-
- Useful references:
-
- [PostScript Language
- Reference](http://www.adobe.com/products/postscript/pdfs/PLRM.pdf)
-
- [PDF Reference](http://www.adobe.com/devnet/pdf/pdf_reference.html)
-
- * [Hard ?] Implement path operations like combine/intersect/overlay
-
- A robust "intersection finder" is at the heart of all of this (that's the hardest part).
- It would start with robust primitives for polygons, intersecting two paths would do a polygonal approximation of the curves,
- do the intersection, and return a path that has no curves in it. And then could be potentially extended to have curves in the output.
- An example of direct 'visible impact' could be an ability to extend cairo's clipping functions with something like `cairo_clip_exclude(cr)`
- and `cairo_clip_invert(cr)`.
-
diff --git a/src/todo.mdwn b/src/todo.mdwn
index 9bc5987..f7f74ec 100644
--- a/src/todo.mdwn
+++ b/src/todo.mdwn
@@ -444,3 +444,144 @@ Not strictly in cairo-land, but noted lest we forget.
* make GdkEditablePixbuf different from GdkPixbuf (treat editing as a special case)
* ensure loaded-from-file pixbufs store their raw image data for writing to JPEG
* possibly add subclasses for themed pixbufs/icon pixbufs and invent a sane object hierarchy
+
+
+Student Projects
+----------------
+The following list of ideas was from Cairo's participation in the Google
+Summer of Code 2008, which saw Joonas Pihlaja undertake a Scan
+converting rasteriser project.
+
+Each idea below is given a difficulty estimate, (Easy, Medium, or
+Hard), determined by one of the potential mentors. Please use these
+ratings to help choose an appropriate project. If a project
+description uses terms you've never heard of and is also rated Hard,
+then you can know that that's a project that will provide plenty of
+learning experiences for you. If a project is rated as Easy, then
+maybe it won't keep your interest and give you the intellectual
+challenge you're looking for.
+
+ * [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.
+
+ * [Medium] Merge XLib and XCB backend similarly to what was done recently to PDF and PS
+
+ Currently there are separate XLib and XCB cairo surface backends.
+ The problem is, the XCB backend is not maintained and does not get
+ the same treatment (bug fixes, improvements, ...) that the XLib
+ backend does. The two also duplicate a lot of code. The idea is to merge
+ the duplicate code, possibly using a similar approach used to make
+ the Postscript and PDF backends share code, namely, cairo-pdf-operators.c.
+
+ * [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.
+
+ * [Hard] Improve software polygon compositing by doing it in a
+ single scanline pass rather than tessellating, rasterizing, then
+ compositing the entire polygon.
+
+ * [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?).
+
+ * [Hard] Add appropriate color-management support to cairo.
+
+ Cairo needs the ability to allow for color management. By this project it
+ will become possible to work in different color spaces, convert
+ automatically to blend different content and tag graphics objects to tell
+ backends about the color spaces involved. The color space information
+ will follow the ICC standard.
+
+ In this project you will learn about the constraints at different OS'es and handle API abstraction.
+ During the programming work you will design and implement the
+ corresponding means covering frontside API's and backend specific code due
+ to file formats and other specific requirements.
+ A small application, showing the new capabilities, will help in spotting
+ problems and can later be used for demonstrations.
+ A unit test and documentation is required for maintainablility and further
+ easy deployment.
+
+ Some relevant threads from various mailing lists:
+
+ - [Color, Cairo and Cups](http://lists.freedesktop.org/archives/cairo/2006-March/006518.html)
+ - [PDF, CMYK and cairo](http://www.nabble.com/PDF,-CMYK-and-cairo-td15636763.html)
+ - [Creating CMYK and spot colors using Postscript backend](http://nashi.altmuehlnet.de/pipermail/scribus/2007-May/023894.html)
+ - [Tessellating complex figures with Render](http://marc.info/?l=xfree-render&m=102121486826819&w=2) contains a subthread on color spaces.
+
+ Ideally this should also incorporate HDR as discussed in the next suggestion.
+
+ * [Medium] Add HDR image surface type to cairo/pixman (`CAIRO_FORMAT_ARGB64`).
+
+ The new image format will implement the [scRGB](http://en.wikipedia.org/wiki/Scrgb) colorspace.
+ This involves either extending the pixman library to support the new format, or write code for
+ Porter-Duff compositing on the new format and make cairo use them for ARGB64.
+
+ Conversions between the 16-bit floats used by colour spaces such as scRGB and 32-bit floats
+ should use the algorithms explained in Jeroen van der Zijp’s [Fast Half Float Conversions](ftp://www.fox-toolkit.org/pub/fasthalffloatconversion.pdf).
+
+ * [Easy] Add a performance/conformance suite for the vector backends.
+
+ One goal would be to aim to make the output file size competitive to other generators (e.g. gs).
+ Conformance could be checked by running the test output through various validators:
+ [SVG validator](http://wiki.svg.org/SVG_Validator).
+
+ * [Hard] Add support for PDF/PostScript Type 6 (Coons patch mesh) and/or Type 7 (Tensor-Product patch mesh) shading functions to the image backend
+
+ The Type 6 shading is a special case of the Type 7 shading so only implementing Type 7 may be all that is required.
+
+ One possible solution would be to create a triangle mesh (similar to Type 4 shadings) from the Type 7 patch mesh and shade the triangles using Gouraud shading.
+
+ The [Poppler](http://poppler.freedesktop.org/) source may be used to get an idea how Poppler renders these gradients . However the approach Poppler uses of recursively breaking each patch into smaller patches then filling the tiny patches with a solid color is not appropriate for cairo due to the visible seams between patches due to antialising.
+
+ The algorithm for Gouraud shading is in many books on computer graphics.
+
+ Useful references:
+
+ [PostScript Language
+ Reference](http://www.adobe.com/products/postscript/pdfs/PLRM.pdf)
+
+ [PDF Reference](http://www.adobe.com/devnet/pdf/pdf_reference.html)
+
+ * [Hard ?] Implement path operations like combine/intersect/overlay
+
+ A robust "intersection finder" is at the heart of all of this (that's the hardest part).
+ It would start with robust primitives for polygons, intersecting two paths would do a polygonal approximation of the curves,
+ do the intersection, and return a path that has no curves in it. And then could be potentially extended to have curves in the output.
+ An example of direct 'visible impact' could be an ability to extend cairo's clipping functions with something like `cairo_clip_exclude(cr)`
+ and `cairo_clip_invert(cr)`.
+
More information about the cairo-commit
mailing list