Re: Live path effects sample from mountain view f2f

Hello SVG folks,

Live path effects are a good example for the different needs and preferences of SVG content creators (the applications) and SVG viewers. 

Content creators need detailed information about the objects, applied effects and so on. This makes it possible to reproduce the steps that were done to make a certain effect possible, to undo, redo them and combine them with other effects.

In my opinion SVG viewers don't care that much about these information. They don't need to know how an effect was created by an application. The viewer just wants to display the content on the display and make it accessible to the user. The main target is performance. The content must be drawn as fast as possible. That is not necessarily a need of content creators. That can be seen in Inkscape with some smaller delays on repainting objects when you apply effects to them. And that is ok for these applications (partly).

Just as an example what needs to be done for the simple example of Chris:
1. Parse the path data (first DOM access)
2. Create the path, apply the stroke style
3. Create the stroke outline path and make sure that is doesn't contain holes by crossing stroke parts. Determine how detailed the stroke path must be. Not all graphics libraries provide these features and it must be covered by the application itself.
4. Get information about path effects (search effects on the DOM, more DOM accesses)
5. Create the transformation function for the path effect
6. Apply transformation function to every element of stroke path
7. Draw the resulting path on the screen

In comparison to the current result of such an effect created in Inkscape for the viewer:
1. Parse the path data
2. Create the path, apply the stroke style
3. Draw the path on the screen

I can understand the needs of content creators. But maybe the way Inkscape is doing it is the best way: add more meta data to the SVG file how the content was created. The Viewer wouldn't care about these information on rendering. The metadata can be archived in an own namespace like Inkscape does it. Most of the users (>95%?) don't care about how the content was created anyway and web developer can decide to remove the meta data of the SVG if they don't want the users to see these information.

I could also imagine to create two profiles: One profile for viewers and one profile for content creators. This could replace the current profile concept tiny, mobile, full, .... The profile for viewers is a smaller subset of the profile of content creators. Once content creators and viewers agree, a certain feature could be added to the viewer profile as well. Or creators use the <switch> element with the modified behavior described by Erik Dahlström. The switch could check for a certain feature of a viewer (even if it is not specified yet). If the viewer doesn't support the feature, the pre-calculated result will get displayed. That would make it possible for SVG Viewers to decide for their selfs which part of the content creator profile match their own needs.

Greetings,
Dirk

Am 29.10.2011 um 02:14 schrieb Chris Lilley:

> Hello SVG,
> 
> The live path effect plus the original path (inkscape:original-d) are small compared to the eventual path which results.
> 
> -- 
> Chris Lilley   Technical Director, Interaction Domain                 
> W3C Graphics Activity Lead, Fonts Activity Lead
> Co-Chair, W3C Hypertext CG
> Member, CSS, WebFonts, SVG Working Groups<drawing-inkscape.svg><drawing-svg.svg>

Received on Sunday, 30 October 2011 06:46:47 UTC