Here another simple example:

When both filling and stroking a path and then drawing it with with an opacity 
of less than 100%, the path will be rendered differently than in an SVG (a 
large stroke width will make the issue more apparent):

- In Canvas, both the fill and the stroke will be rendered with the given 
opacity, and the fill will shine through the inner half of the stroke.

- In SVG, the stroke will cover the fill, and the fill will not shine through 
the inner half of the stroke, regardless of the opacity.

If you'd like to emulate the SVG behavior in Canvas (which we happen to do in 
Paper.js), then the only way to do so currently is to draw the path's fill and 
stroke at 100% opacity into a separate canvas, and then blit the whole thing 
over with the given opacity.

This is *much* slower than directly drawing into the Canvas, and happens to be 
one of the worst bottlenecks in Paper.js

I would really appreciate a solution to this problem.

Jürg

On Mar 14, 2014, at 19:09 , Ian Hickson <i...@hixie.ch> wrote:

> Can you elaborate on what precisely the performance bottleneck is? I was 
> looking through this thread but I can't find a description of the use 
> cases it addresses, so it's hard to evaluate the proposals.

Reply via email to