[CREATE] [OpenRaster] proposal: new layer modes, ref updates, extra properties for layer groups, impact on apps

[Andrew Chadwick]

On 24 February 2014 12:02, Boudewijn Rempt <boud at valdyas.org> wrote:
> Yes, I'm okay with the proposal. Not sure, though, about adding more porter
> duff modes. It could be a long time before I figure out how to support them

More than just the default OVER and the more useful variants of IN and
OUT for masking, I assume? I think Krita's "Erase" is dst-out, and
"Behind" is (I think) dst-over. Not sure if there are others in there
which are pure Duff-Porter.

For efficiency's sake, the branches I've been working on contain
shortcut flags for the modes which tell the rendering engine whether
it can skip empty source pixels (or tiles!) for a mode, or whether a
mode can ever produce an opacity value less than that of a backdrop
pixel (meaningful for MyPaint with its normally opaque background -
we've historically employed a speedup there too, but now sometimes we
cannot). Beyond that sort of semi-empirical categorizing of modes,
there should be no real surprises, particularly if you already support
an Erase mode.

The main question is really whether they might be of use to artists.
dst-out ("masking fluid/tape", "erase"?) and dst-in ("stencil holes",
"mask"?) make nice masks for their stack if they're on top, and I
strongly suggest we recommend that apps implement them both. I'm still
not sure about src-atop, xor and friends, but svg:plus/Lighter might
be quite widely implemented already.

I've no objection to the spec saying that any from Compositing-1 can
be used and specifying the attribute value to use, but also stating
that only a subset of them are likely to be common to all apps.

If this is to be *the* way of storing layer masks in OpenRaster (and I
don't see why it shouldn't be), then we should think about what the
most efficient way of storing the information in PNG would be
(256-colour indexed palettes with a tRNS map, presumably!). But later.

-- 
Andrew Chadwick