[cairo] filters/image processing

[Bill Spitzak]

I feel the best place to put shaders is the compositing step. Basically 
as well as OVER, CLEAR, etc, you would in the future be able to set the 
shader that is used (note that shaders take the existing pixel as one of 
it's inputs and produce the final pixel, so compositing and shading are 
the same thing).

This won't be as powerful as OpenGL as the set of *inputs* to the shader 
is limited to a fixed set: the mask, the path (as an antialiased image), 
the source pattern, the source color, and the destination pixel. I don't 
think cairo should provide a way to add to these inputs. I would think 
an OpenGL implementation would just load the shader (or the built-in one 
for the defined compositing operators) and then draw a rectangle of the 
bounding box of the path.

Shaders could specify the cairo compositing operator they are most 
similar to, and implementations that don't support the shader just use 
that operator. This may also be a good idea for adding new compositing 
operators to Cairo.

I certainly agree that any API that does not correspond to a shading 
language is not a good idea. There is no need to compose shaders, 
because all shader languages are powerful enough that all possible 
composed shaders are also a shader.

, since this is cer

MenTaLguY wrote:
> On Thu, 2006-08-31 at 22:35 -0700, Keith Packard wrote:
>> I'm not sure the pipeline stuff is what we want; GL and DirectX expose a
>> programming language for fragment shaders of this nature. I'd say cairo
>> should either adopt something that matches GLSL or stick with the
>> existing predefined pipeline. Inbetween compromises aren't all that
>> interesting; for programmable hardware, they only lose features.
> 
> 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).
> 
> Even once we provided an API for writing fragment shaders "by hand", I
> suspect many people would still prefer composing primitives with the
> pipeline API for building simple shaders (or building larger shaders by
> composing hand-written ones).