- From: David Dailey <ddailey@zoominternet.net>
- Date: Mon, 3 Sep 2012 12:12:12 -0400
- To: "'Dirk Schulze'" <dschulze@adobe.com>, "'Erik Dahlstrom'" <ed@opera.com>
- Cc: "'Tab Atkins Jr.'" <jackalmage@gmail.com>, "'David Sheets'" <kosmo.zb@gmail.com>, <www-svg@w3.org>, <public-fx@w3.org>
On Monday, September 03, 2012 10:51 AM Dirk Schulze wrote >Actually, what is the problem of copy pasting shaders or use generators? I think >this is more helpful then introducing yet another filter primitive. We already have >enough in my eyes. Introducing more makes it harder to maintain those - from the >spec and the implementor side. I have nothing against regular used short hands, but >another noise filter does not really fit into this concept in my eyes. Well, at present, feTurbulence is the only way in SVG to inject randomness, and as such it is pretty darned essential for painting naturalistic scenes: fire, wood, water, smoke, sand, stucco, lace, shadows, etc. And feTurbulence is severely limited by issues of both speed and the animation periodicity that Erik mentions. Beefing up the capabilities here would be worthwhile from an author's perspective, I think. Yeah, of course the implementers will fuss, but they always fuss! Look how long it got everyone to agree to even play the SVG game! It and feDisplacement are the coolest of the SVG Filters and most of the others are rather ordinary by comparison. By calling these things "primitives" it invokes the mathematical idea of a semantically complete set that allows all possible ideas within the theory to be expressed [1]. At present, the "primitives" are a bit primitive rather than complete. And until we have a good public domain repository of copy-and-paste shaders, I'm certainly not going to be borrowing someone else's given the status of the Treaty of Berne and the tangible fixation of original expressions and all (unless they're Vincent's :) ). Now, if on the other hand, we could convince folks to allow the declarative generation of shaders (say through <replicate> and <random> by drawing the triangle meshes around the 3D shapes generated)... then maybe it would be less problematic to allow feTurbulence to limp along as it is. Maybe, though, just a new parameter inside: <feTurbulence model="fancy"> could handle it (though I suspect that would not mollify the implementers)? [1] http://dl.acm.org/citation.cfm?id=12456 Regards David
Received on Monday, 3 September 2012 16:12:47 UTC