Hi,
On 3/29/06, Arve Bersvendsen <[EMAIL PROTECTED]> wrote:
> Some of you have requested getPixel and setPixel for the bitmap canvas.
> Well, we have some news for you -- Opera has actually had this support all
> along, but we haven't been able to talk about it until now.
Interesting stuff! What are some of the use cases for this, other
than providing color filters? That can be useful, to be sure, but it
seems like a very expensive way to implement that functionality (but
then, expensive is better than not at all)...
> 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:
var pageCanvas = getElement("canvas");
pageCanvas2D = pageCanvas.getContext("2d");
var backBufferCanvas = new CANVAS({});
backBufferCanvas.width = pageCanvas.width;
backBufferCanvas.height = pageCanvas.height;
backBuffer2D = backBufferCanvas.getContext("2d");
// do drawing into backBufferCanvas/backBuffer2D
// update the front buffer
pageCanvas2D.globalCompositeOperation = "copy";
pageCanvas2D.drawImage(backBufferCanvas, 0, 0);
This allows for updating only part of the front buffer region cheaply
(e.g. if you draw a static image/border on the inside of the canvas
and the changing part is only a 50x50 rectangle in the middle, you can
double-buffer just that 50x50 piece), and it also lets you easily
layer elements that are updated at different rates -- e.g. render a
complex infrequently-changing map into canvasA, render a more
frequently changing UI into canvasB, render A and B into the front
buffer, and then render something that's very fast to draw but quickly
changing directly into the front buffer (like a selection rectangle).
> Finally, the opera-2dgame
> context also supports native collision detection, by detecting whether a
> point is within the currently open path on the regular 2d canvas.
This is a useful idea; we'll probably do something similar, though
calling it "collision detection" when it's a "point in path test" is a
little strong. :) We'll probably add a point-in-path method.
Cc'ing the whatwg list on this, as there are interesting canvas API
suggestions involved.
- Vlad
