- From: Charles Pritchard <chuck@jumis.com>
- Date: Wed, 5 Oct 2011 21:37:12 -0700
- To: "robert@ocallahan.org" <robert@ocallahan.org>
- Cc: Vincent Hardy <vhardy@adobe.com>, "www-style@w3.org CSS" <www-style@w3.org>, "public-fx@w3.org" <public-fx@w3.org>, SVG WG <public-svg-wg@w3.org>
- Message-Id: <CFC799E5-DB6A-472B-BD9F-D51693EEDD2B@jumis.com>
On Oct 5, 2011, at 9:08 PM, "Robert O'Callahan" <robert@ocallahan.org> wrote: > On Thu, Oct 6, 2011 at 8:38 AM, Vincent Hardy <vhardy@adobe.com> wrote: > To the question about the effect of shaders on input that goes through > filters, Dean provided the answer I would have given. This is an issue the > group has discussed even before shaders, because it exists regardless of > shaders. Shaders may make things more complex (e.g., points may be moved > in a 3D space and obscure each other before being projected back in 2D > space) but the core issue is the same. Dean mentioned he had an action on > this and I am happy to work with him on it if he would like to collaborate > on a proposal. The reason this is not discussed in the proposal is because > it is not a new issue for filter effects, but may be the proposal should > have said so. > > This is true, but offsets in existing SVG filters have typically not been used to create visual geometry changes. E.g., people use feOffset to create drop shadows and similar effects, but rarely to translate content since the usual transforms are easier to use. I can only recall seeing one demo where feDisplacementMap was used to create a geometric effect. > > On the other hand, your demos show that much of the power of custom filters is in visual geometry changes, such as transforming and warping content. So I think custom filters make the handling of events a much more urgent issue. TL;DR: Authors are (programatically aware of the programmable pipeline: they could use shortcuts for simple vertex shaders and standard interfaces for expressing basic 2d and 3d bounds as simplified for compatibility and accessibility interfaces. .... Events we're maintained in the initial move to 3d and gpu environments: CSSMatrix and transform3d are a good reference. They are simple, programmable pipelines are not. An application author will be quite aware of instances when they are using a programmable pipeline: they should be aware of the best practices for DOM and visual rendering as laid out by WCAG. Though there are opportunities to write pipelines which are practically opaque to the UA, there are also many cases where the pipeline is quite manageable by affine and projection (and heuristically simplified) transforms. As an author, I will have to write additional code to manage extent information on a filter that is applying a user-controlled displacement map. I could use some shortcuts for the more frequently encountered, simple cases and some standard semantics for expressing some of the data structures determined in the scripting environment. -Charles
Received on Thursday, 6 October 2011 04:37:47 UTC