W3C home > Mailing lists > Public > public-fx@w3.org > April to June 2011

Re: Updated filters specification

From: Rik Cabanier <cabanier@gmail.com>
Date: Sun, 1 May 2011 21:06:18 -0700
Message-ID: <BANLkTi=Hh8ye+UfVF6g5bSEggqZb3XE9Jg@mail.gmail.com>
To: robert@ocallahan.org
Cc: Erik Dahlstrom <ed@opera.com>, Dean Jackson <dino@apple.com>, Dirk Schulze <vbs85@gmx.de>, public-fx@w3.org, Anthony Grasso <anthony.grasso@cisra.canon.com.au>
On Sun, May 1, 2011 at 2:29 AM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Sun, May 1, 2011 at 4:54 AM, Rik Cabanier <cabanier@gmail.com> wrote:
>> If the compositing spec were to allow GLSL/OpenCL constructs, then this
>> effect should be possible. (One could argue that CSS blending should ONLY be
>> done with shaders and that the known blendmodes would be built-in shader
>> programs.)
> If you allow arbitrary processing to happen in the compositing spec, you
> are effectively folding the functionality of filters into the compositing
> spec, maybe with different syntax. You'd better discuss with Erik if that's
> what you really want to do :-).
> I know, this would be a large endeavor. :-)
We're seeing that manufacturers are adding hardware support for
blending/filtering to their chipsets. If browsers can tap this, it will
increase what is possible without cutting down battery life or performance.

Do you know much of the CSS/HTML compositing specification has been
I brought compositing up a couple of months ago and Simon Fraser was of the
opinion that it was better to get filters to work first and then move onto
blending later.

The reasoning that blending was too difficult (for now) was that it was hard
to get access to the background.

Received on Monday, 2 May 2011 04:06:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:38 UTC