Re: Filter Templates

On Thu, Feb 24, 2011 at 5:09 PM, Dean Jackson <dino@apple.com> wrote:

>
> On Feb 24, 2011, at 4:56 PM, Rik Cabanier wrote:
>
> > I asked the PixelBender people and they claim that as long as each filter
> can be accelerated on the current hardware, the whole graph will be
> supported. If not, you could switch to software rendering.
> > It is true that not everything can be supported on every device.
>
> I don't believe it is that easy. I mean, it is theoretically that easy - if
> each effect can be accelerated then of course they are all accelerated. But
> there are many tradeoffs to make. For example, if the graph is complex, you
> might be able to optimise it (you could work out that you can crop an image
> before blurring it, because you don't use all the result pixels). In fact,
> you might be able to combine some operations and build a different, but
> compatible, filter graph on the fly using effects/shaders that are not
> directly exposed to the user. It might be difficult to accelerate these, but
> your optimisation might be good enough that the CPU is better anyway.
>
> Anyway, I don't think there is much difference between particular
> technologies here. We all agree we want some canned effects, a way to do
> more complex effects, and the ability to build really fast implementations
> of both.
>

agreed. PixelBender was just a suggestion. If there is something else we can
use that is easier,that would definitely be the way to go.


>
> I would hope that whatever we come up with could be implemented *using*
> PixelBender.
>

yes, and that is not even necessary.


>
> > The nice thing about PB is that it has a software renderer to fall back
> on which is not something that WebGL or feGL offers.
>
> I disagree. There are software implementations of GL. I'm not sure I
> understand here.
>
> The PixelBender language can be considered a subset of GLSL functionality
> that is designed for image effects. Core Image uses something similar. So
> does Collada, and many graphics packages. Writing a software renderer for
> these, or for some feGLSL element, is acceptable and probably required (even
> when you have hardware available).
>

The idea is that PixelBender CPU rendering is faster because it can work
from its own structures as opposed to GLSL emulators that have to start from
code that was tailored to a GPU.


>
> > In addition to support for PixelBender kernels, we could "bake in" a set
> of canned filters which would mirror your list.
>
> Isn't that the plan? We're baking in a set of effects, and giving people
> flexibility via SVG/WebGL.
>
>
Yes, except that I believe WebGL is not a solution because you have to
rasterize your content somehow and then push it to the GPU.That will be slow
and you will loose the HTML behavior.
It could be that I'm missing something... Did you mean OpenGL instead?

Rik