[cairo] Cairo Summit wrapup

Tue Sep 2 17:11:01 PDT 2008

All of us could be there had a wonderful time at the first Cairo Summit.
A big thanks to our gracious hosts, Mozilla!

And our regrets that we couldn't have had everyone subscribed to the
cairo mailing list in attendance. That would have been great fun.

If you catch us in a more casual setting, (in person, IRC, etc.), we can
fill you in on some of the after-hours fun that we had, (rock climbing,
salsa dancing, eating fantastic Mexican food and good gelato, or
finishing up a morning jog by getting chased off a golf course).

But for now, I'll just share some of the progress we made in our hacking
sessions. The notes below are also on the wiki page for the summit,
where anybody can improve them, (I wasn't party to several hacking
sessions so my notes are definitely sketchy):

http://cairographics.org/summit/2008/notes/

I'm looking forward to lots of interesting code and API proposals to
appear on the list soon as a result of this summit. It really was
fantastic!

-Carl

Hacking sessions at Cairo Summit
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.