Re: Thoughts on canvas compositing

On Jan 17, 2011, at 12:47 AM, Paul Bakaus wrote:

> 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.

In WebKit, we look at the z-order hierarchy, sometimes taking geometry into account, to determine what gets into GPU-backed layers. There are various trade-offs here between animation performance, memory usage etc. Generally speaking, if you push your canvas frontwards in the z-order tree, then fewer other elements will hit the GPU path.

> - 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.

Right, this could be something that the browser could detect and optimize for.

Simon