- From: Charles Pritchard <chuck@jumis.com>
- Date: Fri, 15 Jul 2011 10:00:06 -0700
- To: Henri Sivonen <hsivonen@iki.fi>
- CC: Jonas Sicking <jonas@sicking.cc>, Steve Faulkner <faulkner.steve@gmail.com>, HTMLWG WG <public-html@w3.org>, Frank Olivier <Frank.Olivier@microsoft.com>, Richard Schwerdtfeger <schwer@us.ibm.com>, Cynthia Shelly <cyns@microsoft.com>, David Singer <singer@apple.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Edward O'Connor <hober0@gmail.com>, Canvas <public-canvas-api@w3.org>
On 7/15/2011 8:11 AM, Henri Sivonen wrote: > In theory, SVG should be able to outperform<canvas> for painting, > because the browser engine gets to control how often to repaint, what > parts to repaint and can avoid intermediate bitmaps when the path > stroking and filling can be performed nearer hardware and there are > guaranteed not to be readbacks because the browser knows there aren't > filters in use. Your theory applies to WebGL v. Canvas 2d; webgl data types are setup to run on gpu hardware. By and large, shapes in canvas 2d and/or svg will have to be tessellated or rendered on the cpu prior to uploading to the gpu, as bezier curves are not a primitive in gpu-world. As for filters; that is again something for webgl and/or css. CSS 3d transforms, for instance, do send canvas 2d and svg data over to the gpu so the gpu can perform the filters. WebGL shader chains certainly run faster on GPU than CPU. It's quite possible for SVG filter chains to be "gpu-enabled" and to be applied directly to Canvas content. Mozilla has the css filter type. For various reasons, filters can be a little slow to compile, but otherwise, they're quite handy. -Charles
Received on Friday, 15 July 2011 17:00:29 UTC