Fwd: [cairo] [PATCH] PDF: alpha-gradients; reused patterns; cairo_paint_with_alpha

[Kristian Høgsberg]

---------- Forwarded message ----------
From: Kristian Høgsberg <krh at bitplanet.net>
Date: Jul 26, 2006 11:19 PM
Subject: Re: [cairo] [PATCH] PDF: alpha-gradients; reused patterns;
cairo_paint_with_alpha
To: Miklós Erdélyi <erdelyim at gmail.com>


On 7/25/06, Miklós Erdélyi <erdelyim at gmail.com> wrote:
> On 7/25/06, Kristian Høgsberg <krh at bitplanet.net> wrote:
> > Pattern reuse is definitely useful, and hashing for this purpose is
> > probably fine, but since you're already hashing the patterns, consider
> > using cairo_hash_table_t.
> I will give it a try. Please find the gradients+stroking/non-stroking
> operators separated plus paint_with_alpha patch attached (they have to
> be applied in the beforementioned order). I hope this can be now
> committed. I haven't polluted the mailing list with these.
>
> > > Also, when is it planned to add the surface serial stuff?
> > It's just a matter of writing the patch ;)  It's probably less work
> > than the hashing code you already did - add the serial number to
> > cairo_surface_t, change each cairo-surface.c entry point to bump the
> > number and you're done.  It's of course a cairo 1.4 thing at this
> > point.
> I might write this then :) How would you calculate the serial?

Just start from 0 and increase it everytime the surface is modified.

> The problem with this approach is that it still doesn't handle
> identical image_surfaces for example. Generating a checksum/hash for
> the image data is required to reuse image patterns. A lot of space can
> be saved with this for example when a company logo is displayed on
> every page... If you draw it with native cairo then it won't be
> repeated in the stream (because the same surface will be used). But
> for example when exporting to PDF from Inkscape the images are always
> recreated for cairo (though this might change when they'll move to a
> Cairo-based renderer) so it would be emitted into the the stream every
> time it's printed.

Well, that's a good point... on one hand I think that the case where
somebody repeatedly creates a cairo surface for the same bitmap data,
is not something we need to optimize for, but on the other hand the
code is there and handles this case.  However, CRC32 isn't suitable
for this use.  It's a checksum algorithm designed for detecting
transmission errors, that is, small bit deviations from the original
message, not for reliably representing the contents of an image
surface as a 32 bit checksum.  So if we want to do this, we need
either 1) a more reliable hash that can be used to represent the image
data, or 2) keep all emitted images in memory and compare against
these to see if we already have the image in the PDF document (note,
we can keep images in a hash table in this case and use CRC32 as the
hash function). For 1), we need to pull in something like SHA-1, but
I'm not sure it's worth it at that point, and 2) doesn't scale.

> > Another concern is that we probably want a versioning system as for
> > the SVG surface.  The smask feature was introduced in PDF 1.4 and many
> > viewers don't yet support that.  The SVG surface has
> > cairo_svg_surface_restrict_to_version() and related functions, and the
> > PDF surface should use a similar mechanism.
> This would make sense if the fallback images would be generated for
> only the relevant part of the surface. Otherwise what could be done
> with for example gradients? Maybe premultiplying the color stops with
> alpha? Or just ignoring them? Or other wizardry?

The fallbacks are supposed to only cover the part of the page that
needs the fallback.  Right now they don't but the infrastructure is in
place to optimize this.  From a surface backend point of view, all you
need to do is return CAIRO_INT_STATUS_UNSUPPORTED.  As you mention, it
is possible to do better in some cases, for example, if the background
color is known to be constant across the gradient, you can just
pre-composite the gradient color stops over the background color and
do an opaque gradient.  You can do lots of other tricks here, but my
take is that it's not worth pursuing very far - the more you want to
optimize, the more complicated it gets, and the smaller the gains.

Having said all that, we already use smask's in the PDF surface, so
don't let the versioning issue block your work.

Btw, do try to follow the coding style of the rest of cairo.
CODING_STYLE documents most of the conventions used, but when in
doubt, copy the style of similar constructs elsewhere in cairo.

Kristian