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

Tue Sep 2 17:04:27 PDT 2008

src/summit/2008/notes.mdwn |  199 ++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 198 insertions(+), 1 deletion(-)

New commits:
commit 2ed7a2b779b2fbfe13d28de0fcc6dd547bb799fb
Author: Carl Worth <cworth at cworth.org>
Date:   Tue Sep 2 17:03:57 2008 -0700

    Add writeup of hacking sessions

diff --git a/src/summit/2008/notes.mdwn b/src/summit/2008/notes.mdwn
index ee87464..d6108dd 100644
--- a/src/summit/2008/notes.mdwn
+++ b/src/summit/2008/notes.mdwn
@@ -290,7 +290,7 @@ specification without cairo API. We probably don't want to implement
 all of that. One idea is a generic API for inserting an arbitrary PDF
 object, allowing us to offload the work to an external
 library---that's especially useful for the non-graphical portions of
-PDF. As for graphical stuff, probbaly the only piece we're really
+PDF. As for graphical stuff, probably the only piece we're really
 missing is mesh gradients.
 
 Vlad: To what extent is cairo the be-all-and-end-all solution for PDF
@@ -349,3 +349,200 @@ months or so). Targeting OpenGL ES 2.0 seems like the right thing.]
 
 Joe plans to make a first attempt at an OpenGL backend and will talk
 about it on the cairo list.
+
+Wednesday and Thursday, August 27-28, 2008
+==========================================
+
+On days two and three of the summit, we switched gears from group
+discussions of topics to instead have hacking sessions. For the
+hacking sessions, we chose tasks which we thought we could make some
+significant progress on in a couple of days, and which would benefit
+from 2 or more people who don't normally get the chance to work
+together.
+
+We didn't make any written notes at the time, but here are some
+writeups made after the fact. (Some of the details and participants of
+these hacking sessions will be missing---we had up to 3 or 4 going on
+simultaneously, so I couldn't attend them all. Please add anything
+missing.)
+
+Making the PDF backend emit shared source images only once
+----------------------------------------------------------
+
+Adrian, Carl, and Chris spent quite a bit of time on this issue and
+made some excellent progress. After initial discussion, we were able
+to divide the work up into 3 separate pieces with agreed-upon
+interfaces.
+
+Chris implemented a new global counter for every surface created, and
+another per-surface counter for each operation that modifies a
+surface. Carl reviewed this, and Chris completed round 2 with new
+naming.
+
+Adrian completed most of the work necessary to augment the current
+array of source patterns stored by the PDF backend with a new hash
+table keyed off the two counters implemented by Chris.
+
+Carl planned to provide the final piece which is a copy-on-write
+implementation for _cairo_surface_snapshot, (so that when the
+meta-surface makes duplicate snapshots of an identical surface the PDF
+backend will see identical keys). Without the copy-on-write
+implementation, the current snapshot code is currently making explicit
+copies, so no sharing is possible. Carl did not get much time to work
+on this at the summit, so this task will need to be finished later.
+
+Improving the build on Windows and OS X
+---------------------------------------
+
+Travis, Antoine, and Fred spent a lot of time battling configure
+scripts, and libtool, etc. trying to get builds more friendly to
+Windows and OS X. The consensus was to remove the version number from
+configure.in and the file lists from Makefile.in putting them into
+simple files. These files could then be included by
+configure.in/Makefile.in as well as by alternate platform-specific
+Makefiles. Behdad did some work on this extraction, which we hope to
+see soon.
+
+JIT for pixman
+--------------
+
+SÃ¸ren has been investigation some JIT ideas for pixman for a while. He
+had the chance to meet with Mozilla developers, (didn't catch the
+names), that have been working on Nanojit---a JIT engine that Mozilla
+is using (will use?) for Javascript. This looks potentially
+interesting for pixman, but there are some licensing issues to work
+out, (Nanojit comes from Adobe originally, with the MPL license while
+pixman will need an MIT license).
+
+Setting up cairo buildbot instances at mozilla
+----------------------------------------------
+
+Vladimir took on this task, and made some good progress getting things
+working. He also succeeded at locating suitable hardware already at
+Mozilla. We had a useful conversation about many desirable features:
+Developer access to machines of various platforms, the ability to
+submit patches to the buildbot for testing across the platforms,
+reports on test suite and performance suite, etc. Clearly the right
+answer is to get the minimal thing working and to add additional
+features incrementally.
+
+Fixing test-suite failures
+--------------------------
+
+Chris and Carl had only a very little time to look at this issue. Carl
+is getting 8 failures on the image backend, (which should really
+always have 0 failures). Five of these have apparently never passed
+and are related to the LCD_FILTER API, which Carl had already wanted
+to just remove. Behdad agreed grudgingly. The remaining 3 failures
+look simply like rasterization differences which Carl didn't track
+down yet.
+
+Improving image downscaling quality
+-----------------------------------
+
+Antoine has had some patches for some time in this area, and appeared
+to have some very fruitful discussions with SÃ¸ren about them. Various
+ideas could be heard being thrown out about the best way to address
+the problem, and we hope for good things soon.
+
+Getting JPEG data into PDF output
+---------------------------------
+
+Adrian has had reasonable code for this for a while, and just needed
+some help nailing down the API. Everyone seemed to have their own idea
+about the ideal API, (should it be on the pattern or the surface? on
+any pattern or just a surface pattern? on any surface or just an image
+surface?). But we finally did reach consensus, (which Adrian will have
+to remind us of on the list).
+
+Using doubles in the tessellator
+--------------------------------
+
+Antoine has a patch for this, but we only had time for a very brief
+conversation about it. Antoine knew that Carl had some concerns about
+precision, but we only really had time for Jeff and Antoine to
+convince Carl that 52 is in fact greater than 32 and the
+conversation ended there. (Only on the way home did Carl realize that
+the current fixed-point implementation is actually using 64 and 128
+bits, so this issue remains open.)
+
+Reviewing Joonas' rasterizer work (Summer of Code)
+--------------------------------------------------
+
+Unfortunately, we did not succeed at getting Joonas to join us at the
+summit, but he did dial in to give us a nice overview of his
+progress. He did some great work surveying/benchmarking various
+existing polygon-rasterization implementations, implementing his own
+ideas, and integrating the best into cairo. The current results show
+up to 2x improvement on complex polygons. (The most simple,
+pixel-aligned rectangular paths still have 10x slowdowns, so some
+special-case code for those will still be needed---the code for this
+should all be within cairo already and just needs to be hooked up).
+
+Static analysis for cairo
+-------------------------
+
+David Mandelin made a special guest appearance at the Cairo Summit to
+give an overview of two static-analysis tools being developed and used
+at mozilla:
+
+DeHydra (http://developer.mozilla.org/En/Dehydra)
+
+TreeHydra (http://developer.mozilla.org/en/Treehydra)
+
+These hook into the gcc frontend and export the ability to write rules
+with Javascript that operate on the gcc data structures. We have
+various things we've been wanting to do with static analysis in cairo,
+(verifying that integers and fixed-point values don't get confounded,
+that user-space and device-space don't get confounded, that
+cairo_status_internal_t values don't leak out, etc.).
+
+So it will be worth looking into these tools, (as well as sparse), to
+see how to implement some of those.
+
+Image clamping
+--------------
+
+This may have been the only hacking session idea that we didn't get to
+spend any time on. Too bad---it would have been fun.
+
+Mesh gradients
+--------------
+
+Adrian and Travis spent a lot of time poring over the mesh gradient
+specification in the PDF reference. The big challenge is coming up
+with "cairo like" API to capture the tremendous amount of data
+necessary to specify a mesh gradient. With Carl's help, a sketch of
+such an API did form, (with a series of cairo_mesh_pattern_curve_to
+calls to incrementally construct the mesh similar to the way a path is
+constructed).
+
+There are lots of details missing to turn the sketch into a complete
+API, but Adrian feels like he has enough of an idea now to no longer
+be blocked.
+
+The "chain of bugs" issues
+--------------------------
+
+We didn't come up with any better name for these bugs, but they are
+all detailed in Carl's blog post here, (and google knows that this is
+what "chain of bugs" means):
+
+http://www.cworth.org/cairo/a_chain_of_bugs/
+
+Of the three bugs mentioned there, bug #1 does not appear in current
+Mozilla builds, but similar issues are sure to appear again,
+(basically, the rest of the bugs are ready to be exposed by anything
+triggering fallbacks).
+
+For bug #2, Adrian found one problem in cairo's PDF output, (an
+overly-large BoundingBox property that was causing the fallback-region
+to expand), and Jeff agreed that it should be possible to convince
+poppler to just use SOURCE for simple knockout groups, (which is what
+cairo really wants). We opened this bug report to remember that issue:
+
+Simple knockout groups should just be rendered with CAIRO_OPERATOR_SOURCE
+https://bugs.freedesktop.org/show_bug.cgi?id=17346
+
+We didn't get a chance to look closer at bug #3, so that will have to
+wait for another day.
