Re: Thoughts about variable-width strokes in SVG2

On Mon, May 6, 2013 at 11:30 PM, Brian Birtles <bbirtles@mozilla.com> wrote:

> Hi Rik,
>
> Thanks for your feedback here.
>
> (2013/05/07 14:59), Rik Cabanier wrote:
>
>>     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.
>>
>>
>> Sure. Why would you vary the width by the points though.
>> A user doesn't know about beziers; he just uses his figure to draw
>> something. It would be very weird to have the width vary by hidden points.
>>
>
> Because as you push harder on the tablet or you rotate the stylus to use
> only the narrow end you expect the stroke width to change.


OK.
Will that pressure point coincide with an actual point? What if you just
draw a straight line?

>
>
>      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.
>>
>>
>> Why is that? It seems like that can happen anywhere.
>> Why would you even offload it? The overhead of threading will be more
>> than just calculating it.
>>
>
> I don't think I understand what you're saying. The calculations required
> to render a variable-width stroke can potentially be done asynchronously
> along with other rendering. The work in script is almost certainly going to
> be done synchronously.
>

What 'work in script'? The use case you talk about could simply record
pressure + the line drawing. Calculating the lenght of a path is trivial so
turning the pressure points into percentages is too.


>
> This is probably not significant though. The bigger issue is the amount of
> code required to do something common.
>
> Note that the application I have in mind is not the only one doing this.
> SVG Edit's freehand path tool also builds up paths in this way.
>
>
>      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.
>>
>>
>> Sure. At the Sydney F2F I had many Illustrator examples. I'll see if I
>> can dig that wiki page up again.
>>
>
> Yes, that's good but what's really needed is Web apps. We can already
> represent Illustrator's variable-width strokes in SVG using paths (that's
> how Illustrator exports them). What we *can't* do with SVG is allow those
> paths to be created on-demand and manipulated without doing a *lot* of math
> in script.


Yes. If we have variable width strokes, there's no need for math in scripts
or for Illustrator to outline them.


>
>
>      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.
>>
>>
>> Let's say we have 2 bezier curve and the stroke gets thicker in the
>> middle. This 'thickening' follows a catmull rom curve.
>> Now, we subdivide the beziers in half so we have 4 curves. How can we
>> preserve the same appearance of the variable width stroke? It doesn't
>> seem easy to do with your proposal. (C
>>
>
> Yes, I agree something like this could be very useful but I'd like to see
> the actual application first. Why are we subdividing it?
>

It is very common to add points to a curve to do small adjustments.


>
> As I suggested above, once we know that we could possibly modify (C) to
> accommodate this (perhaps by having a means of representing gaps or
> augmenting (C) to allow particular widths to be tied to fixed indices.)
>

I think that's more complicated than it needs to be.
You most likely want to reuse a variable width stroke definition across
multiple paths. Tying it to points makes that impossible.