Re: Thoughts on canvas compositing

Hi everyone,

Thanks for the input, very appreciated. Let me add some additional thoughts regarding your answers:

- GPU context handling of Canvas: This is interesting, since I've been testing the creation of GPU contexts extensively with WebKit, but without Canvas. Yes, you are creating fast GPU contexts, but the problem then is the opposite: All adjacent elements or close-by elements (seems to be filtered by z-index ranges, and proximity) will also go into the GPU path, unfortunately allocating way more memory than mobile browsers can handle. This isn't even canvas specific, I wonder if anything can be done about it.

- Fullscreen API: I've totally forgot about this possibility, this sounds like a great way for browsers to bypass compositing if fullscreen. Thanks for the pointer!

- Attributes: I admit it is not beautiful, I'm all for simplicity. A valid alternative would be to detect if the canvas and all elements overlapping or underlapping it have a non-transparent background value set, and then go faster. I'm unsure with browser internals, but I suspect there might be a heavily optimized route ahead if no alpha transparency is involved.

Thanks,
Paul

Von: Charles Pritchard <chuck@jumis.com<mailto:chuck@jumis.com>>
Datum: Mon, 17 Jan 2011 00:20:42 -0800
An: "robert@ocallahan.org<mailto:robert@ocallahan.org>" <robert@ocallahan.org<mailto:robert@ocallahan.org>>
Cc: Simon Fraser <smfr@me.com<mailto:smfr@me.com>>, Paul Bakaus <pbakaus@zynga.com<mailto:pbakaus@zynga.com>>, "public-canvas-api@w3.org<mailto:public-canvas-api@w3.org>" <public-canvas-api@w3.org<mailto:public-canvas-api@w3.org>>, "public-fx@w3.org<mailto:public-fx@w3.org>" <public-fx@w3.org<mailto:public-fx@w3.org>>
Betreff: Re: Thoughts on canvas compositing





On Jan 16, 2011, at 1:55 PM, "Robert O'Callahan" <robert@ocallahan.org<mailto:robert@ocallahan.org>> wrote:

On Mon, Jan 17, 2011 at 10:18 AM, Simon Fraser <<mailto:smfr@me.com>smfr@me.com<mailto:smfr@me.com>> wrote:
That's not true of all user agents. For example, WebKit on Mac will use a fast, GPU-based path for compositing a WebGL canvas. It's

The same is true for Firefox 4 everywhere we have enabled usage of the GPU (currently Mac and Windows for drivers we trust). I believe it's also true for IE9. It's also true for 2D canvas on those browsers.

I really don't see the need for any new properties. I think the onus is on the browser developers to detect and implement compositing optimizations when they can.

I agree.

I'd like to point out that 2D rendering, of bezier curves, is tricky on most older gpus-- and is often rendered on CPU then sent to the gpu.

3D gaming and 2D shaded animations are two very different problem sets.

Yes, the latest and greatest cards have wonderful support/potential.

Most of the computers on the market don't have that same amazing potential. CSS transforms and opacity are the bare basics which can be easily accelerated in those environments.

As the OP is from Zynga, I'd say, use the tricks that work with the widest audience.

2D on graphics cards, of the quality OP is looking for, is relatively new. And for complex scenes, using webgl shaders is where excitement is going to be, on supporting cards, and can be run efficiently on multicore systems that don't have a programmable pipeline.

-Charles