- From: James Robinson <jamesr@google.com>
- Date: Tue, 4 Sep 2012 09:30:26 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: whatwg@lists.whatwg.org
I believe this ship has already sailed for the most part - several major browsers (starting with IE9) have shipped GPU based canvas 2d implementations that simply lose the image buffer on a lost context. Given that there are a fair number of benchmarks (of varying quality) around canvas 2d speed I doubt vendors will be able to give up speed. It's also important to note that unlike WebGL the only thing lost on a lost context is the image buffer itself. With WebGL, the page has to regenerate a large number of resources (shaders, buffers, textures) before it can render the next frame. With canvas the page can just start drawing. Many applications redraw the entire canvas on every frame so lost context recovery is identical to normal operation - just draw the thing. All other resources are managed and can be regenerated by the browser without script intervention. On Mon, Sep 3, 2012 at 9:11 AM, Ian Hickson <ian@hixie.ch> wrote: > There are ways to make it work without forgoing acceleration, e.g. taking > regular "backups" of the canvas contents, remembering every instruction > that was sent to the canvas, etc. > We investigated these and other options when first looking at GPU acceleration in Chrome. None seemed feasible. Readbacks are expensive. Bandwidth from GPU to main memory in split memory systems is limited and doing a readback is a pipeline stall. Recording draw commands works for some path-only use cases but many canvases reference from dynamic sources such as <video>s or other <canvas>es. Preserving these resources around is quite expensive, especially when they might be GPU-resident to start and require a readback. The more basic problem with all of these approaches is that they require considerable complexity, time and memory to deal with a (hopefully) rare situation. There will never be a benchmark that involves a context loss in the middle, so any time spent on recovery is time wasted. > On Mon, 3 Sep 2012, Benoit Jacob wrote: > > > > Remember this adage from high-performance computing which applies here > > as well: "The fast drives out the slow even if the fast is wrong". > This isn't an issue of the spec -- there is existing content that would be > affected. > > It is the spec's problem so far as the spec wants to reflect reality. I really doubt UAs are going to be able to implement something significantly more complicated or slow than what they have been shipping for a few years. I think it would be useful for some sorts of applications to be notified when the image buffer data is lost so that they could regenerate it. This would be useful for applications that use a canvas to cache mostly-static intermediate data or applications that only repaint dirty rectangles in normal operation. - James
Received on Tuesday, 4 September 2012 16:30:57 UTC