W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2006

[whatwg] [canvas-developers] Opera with support for getPixel/setPixel

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 3 Apr 2006 02:27:53 -0700
Message-ID: <C77F735C-1A8C-420F-BA49-F2243581CDD6@apple.com>

On Mar 29, 2006, at 10:26 AM, Vladimir Vukicevic wrote:

>> In addition to supporting getting and setting of individual  
>> pixels, we
>> also support locking of the canvas and better control over the redraw
>> process, for optimized performance in games.
>
> What happens if an exception is thrown while you have the canvas  
> locked?
> This also seems like it requires you to always copy the current canvas
> contents at lock time. Locking seems like just a roundabout way to
> achieve double buffering, when explicit double buffering could be
> better.  Instead, I've been suggesting that if people need double
> buffering (and it's a good idea), that they implement it themselves,
> with full control over the are that's double buffered, when they
> update, etc:

In rendering engines that already provide double buffering, the  
ability to lock the canvas would not be very useful. For example, in  
Safari/WebKit if you do a bunch of canvas drawing in a single run of  
JS code, it will all get double-buffered and won't be drawn to the  
screen until the next run loop cycle, where it will update along with  
the rest of the page. Unless the intent is to lock a canvas across  
multiple event loop cycles (e.g. from one JavaScript timer to another  
later one) but that seems like a bad idea.

A canvas implementation really needs a backing buffer anyway to be  
able to properly handle redraw and layering, so I'm not sure what the  
lock ability buys over just always double-buffering.

Regard,
Maciej
Received on Monday, 3 April 2006 02:27:53 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:46 UTC