[cairo] filters/image processing

[Vladimir Vukicevic]

On 9/1/06, Keith Packard <keithp at keithp.com> wrote:
> On Fri, 2006-09-01 at 13:07 -0400, MenTaLguY wrote:
>
> > Would it be an in-between compromise, though?  I mean, the idea here is
> > to provide a basic API with composable filter primitives, but that
> > doesn't preclude later adding the ability to write custom primitives for
> > it as fragment shaders (and, in an ideal world, compiling the entire
> > pipeline to a fragment shader behind the scenes).
>
> So do the programmable bits first and let people write utility libraries
> that generate programs. A GLSL "compiler" would actually be easier than
> what you're proposing; GLSL is effectively an assembly language and
> closely maps to 3D hardware execution engines (no surprises there).

A programmable pipeline for simple convolution filters would be
overkill, and would also be unimplementable on almost all platforms
without dragging in Mesa and doing things in software anyway.  Once we
get to a point where we can use OpenGL on all platforms, this may be
more feasable, but as it stands now OpenGL as a generic solution isn't
usable on any of Linux, Windows, or OSX -- though on OSX it's probably
the closest.  If it was possible to do so, we wouldn't need all the
various cairo backends and would just have the glitz backend.

However, doing a full pipeline metaphors with variables and whatnot is
overkill, I think; create an API to apply a convolution filter, and I
think you cover a large chunk of current use cases  (shadows,
blur/sharpen, etc.).  (It doesn't get you full SVG, but I don't think
full support for SVG filters is an interesting goal.)

    - Vlad