W3C home > Mailing lists > Public > www-style@w3.org > October 2011

Re: [css-shaders] CSS shaders for custom filters (ACTION-3072)

From: Chris Marrin <cmarrin@apple.com>
Date: Fri, 07 Oct 2011 09:42:57 -0700
Cc: Gregg Tavares <gman@google.com>, Dean Jackson <dino@apple.com>, www-style@w3.org
Message-id: <EBAAD700-8919-4D06-99C0-4D5FE6BFD24F@apple.com>
To: robert@ocallahan.org

On Oct 6, 2011, at 6:28 PM, Robert O'Callahan wrote:

> On Fri, Oct 7, 2011 at 5:44 AM, Chris Marrin <cmarrin@apple.com> wrote:
> But imagine an author who wants to use a very dense mesh to get smooth curves to closely match the curve effect you can get from a fragment shader. Mapping mouse positions with such a mesh would require thousands of matrix operations, including inverse which is very expensive. Especially on mobile hardware, this would be too expensive to be practical.
> 
> When native apps need to do this sort of thing they often will construct a second, simpler set of geometry which animates along with the finer mesh and is used for things like picking and collision detection. We could do something like that, but it would probably be hard to come up with the right heuristics.
> 
> Choosing a smaller mesh size for picking doesn't sound hard.

Not hard to choose the mesh, but maybe hard to apply the vertex shader to it. Some vertex shaders might be tied to the mesh size, so they wouldn't transform the smaller mesh correctly. I'm not sure if that's a realistic concern, but it seems like such a shader would certainly be written by someone!

> 
> And it would still require running the shader in software, which would be quite a big impediment to many implementations.
> 
> Yes, this is my biggest worry.
> 
> I think for now it would be best to not deal with the picking issue and to hang on to filter-margin to deal with bounds issues.
> 
> If we decide to ignore the event handling problem, then I think implementations should completely block mouse events from going to the descendants of an element with a custom filter with a vertex shader. If apps want to handle those events they can catch them on the filtered element and perform the coordinate translation themselves. Then later if we decide we want to support event handling properly, we can add syntax to let authors opt into it. This will give us more interoperable behavior, and also better behavior I think --- you don't want mouseovers in one place to light up an element in another place.

Yeah, that does seem reasonable. But I admit it's not very appealing...

-----
~Chris
cmarrin@apple.com
Received on Friday, 7 October 2011 16:43:53 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:45 GMT