- From: Jürg Lehni <lists@scratchdisk.com>
- Date: Thu, 3 Apr 2014 08:21:38 +0200
- To: Ian Hickson <ian@hixie.ch>
- Cc: Rik Cabanier <cabanier@gmail.com>, Justin Novosad <junov@google.com>, WHAT Working Group <whatwg@whatwg.org>, public-canvas-api@w3.org, Brian Salomon <bsalomon@chromium.org>
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 <ian@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.
Received on Thursday, 3 April 2014 06:22:13 UTC