On 10/27/06, MenTaLguY <mental@...3...> wrote:
On Fri, 2006-10-27 at 12:58 -0700, Carl Worth wrote:
That may be too. But GEGL's going to be all-software, right? (At least for now). I agree we don't need to provide an API in cairo to be able to do totally arbitrary effects, but when something like a convolution filter is _so easy_ for almost any hardware to do, it's a shame that cairo isn't exporting any easy way to get at that.
Yeah... unfortunately for Inkscape, we still need to implement the rest of the SVG raster effects as well. If I understand correctly, GEGL already provides them, so I'd tend to choose it over re-implementing them manually. At that point we may as well use GEGL for blur too, rather than attempting some kind of messy mixed-mode arrangement.
GEGL doesn't yet implement all of the SVG raster effects. Some are implemented, some under way and others waiting for someone to code them. I've also considered making the XML parser for GEGL compositions support reading SVG filters (and reuse them in the composition trees already supported by the XML parser.)
But, the other part of it is that the GEGL API does seem amenable to acceleration if someone wanted to do it now, and the architecture of a cairo-based filter API is likely going to have to be similar in design. Is this a wheel we need to reinvent in cairo?
Cairo wouldn't necessarily want to reinvent the entire wheel, but at least provide means to use the commonly desired filters that lend themselves easily for hardware acceleration. To me GEGL as a dependency for cairo seems top-heavy.
Optimization has not been a priority for GEGL yet, And it is designed to be able to cope with larger than RAM images with processing done with 128bit/pixel (32bit floating point/component). Lesser demands that can be optimized are taking a back seat to get a reference implementation with readable code working first.
The reason there is no release of GEGL yet, is that time has not been found to verify exactly what APIs should be exported, and how to present that API. There is working test code now, it exercises and demands expansion of the public API, this will probably help solidify the needed APIs.
Once GEGL itself works well enough, with a stable API. Focus will probably be diverted to adding support for registering optimized paths for different pixel formats (where some of the formats might indicate GPU processing).
/Øyvind K.