- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Fri, 21 Mar 2014 12:24:11 +1300
- To: Justin Novosad <junov@google.com>
- Cc: Dirk Schulze <dschulze@adobe.com>, "whatwg@whatwg.org" <whatwg@whatwg.org>, Rik Cabanier <cabanier@gmail.com>
On Fri, Mar 21, 2014 at 8:15 AM, Justin Novosad <junov@google.com> wrote: > Sorry for the confusion, the point I was trying to make was unrelated to > the CTM question (almost). My point is that the tesselation of a path is > something that can be cached in a Path2D object. > > If you do this, you can take advantage of the cached tessellation: > (apply tranform 1 to ctx) > ctx.fill(path1) > (apply tranform 2 to ctx) > ctx.fill(path2) > > If you do it this way, the aggregated path needs to be re-tesselated each > time because the winding rule would need to be re-applied: > (apply tranform 1 to ctx) > ctx.addPath(path1) > (apply tranform 2 to ctx) > ctx.addPath(path2) > ctx.fill(); > > Technically, these two ways of drawing are not equivalent (depends on > compositing mode, transparency, and winding rule, overlaps between paths), > but they can be used to achieve similar things. Nonetheless the second way > is detrimental to performance, and we'd be encouraging it by providing an > addPath method on the context. Besides, if the dev really needs to add > paths together, it can be done inside an intermediate path object. > An implementation can turn #2 into #1 if the paths obviously don't overlap. If they might overlap, the author probably shouldn't be doing the latter! TBH I don't see why authors would choose the latter approach. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w
Received on Thursday, 20 March 2014 23:25:19 UTC