- From: Maciej Stachowiak <mjs@apple.com>
- Date: Mon, 3 Apr 2006 02:27:53 -0700
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