Re: Thoughts about variable-width strokes in SVG2

(2013/05/07 14:24), Rik Cabanier wrote:
>     (2013/05/07 13:00), Rik Cabanier wrote:
>
>              Regarding question 1 (how to position the widths), option
>         (A) is
>              problematic. Every time you add a point to the <polyline>
>         you would
>              have to adjust all the other stroke width offsets since
>         they are
>              based on a percentage of the path length and the path
>         length has
>              changed. That's clumsy and slow (and speed really matters
>         for this
>              app on mobile).
>
>
>         How common would that be?
>         Even so, you have to stroke again if you add a point so the
>         calculation
>         needs to be redone anyway.
>
>
>     I guess I didn't explain the use case very well. You add a point to
>     the <polyline> on every single pointer event, i.e. several times a
>     second.
>
>
> How common is that?

What I'm describing is an application where you build up a path by 
drawing. Drawing using touch events is very common in mobile apps.

>     I'm focussing on the useability from an *authoring* point of view,
>     not an *implementation* point of view.
>
>      From an authoring point of view, using approach (A), in script you
>     have to recalculate *all* the offsets on *every* pointer event.
>
>
> Calculating an offset is easy and fast. The calculation of the variable
> width will be hundreds of times slower.

It's not an offset, it's every single offset in the path. Your input 
data is a series of points and radii/pressure values corresponding to 
those points. That's just how touch events and pointer events are 
spec'ed so it's fixed.

To use a percentage-based approach you will most likely need to maintain:

* the previous point
* the list of offsets
* a pre-calculated list of cumulative chord lengths

When you get a new point you will need to walk that list of offsets and 
recalculate every one of them, then serialize them into a new list.

That's a fair bit of code to write particularly when it's not 
necessary--with approach (C), you just append a value on to the 
'stroke-widths' property.

What's more, although it can probably be done quite cheaply it will 
typically be done on the main thread unlike the variable-width stroke 
drawing.

>     Using approach (C) you don't need to calculate anything.
>
>
>   That's not how variable width strokes are used though. I was under the
> impression that they are most commonly used to imitate brush strokes.

I'm describing a real-world use case. This *is* how I want to use them. 
If someone has a real-world use case where they want to imitate brush 
strokes then it needs to be sent to the list so we can analyse it.

Let's build the feature from the use cases, not the other way around.

 > You also have to think about how they work. Adding points to a stroke
> shouldn't affect the 'curve' of the variable width.

What's the application though? Why are you adding points to the stroke? 
Once we have a real application we can determine how to approach it. It 
might be a modification of the points-based approach so that you can 
have gaps, or fixed offsets (as I suggested in the original mail). But 
without a real application we can only guess.

Best regards,

Brian

Received on Tuesday, 7 May 2013 05:48:05 UTC