W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2008

[whatwg] Canvas comments

From: Oliver Hunt <oliver@apple.com>
Date: Fri, 1 Feb 2008 00:27:10 -0800
Message-ID: <F8671A42-F835-4D41-A509-8E3C1DBE0F75@apple.com>
... lots of stuff that hixie has already responded to ...
> * There's no fast way to edit the pixels on the canvas.
>  putImageData and getImageData are glacial, as is fillStyle= +  
> fillRect().
>  Byte arrays (well, if strings were bags of bytes, they'd work too)  
> or a
>  shader language, maybe? I don't know.
I believe Hixie is already looking at speccing the ImageData object to  
require a fast native
backing buffer (i could be wrong), but i'll add my two cents here.

putImageData is not slow.  I've done a number of timings for blitting  
a 200x200px square,
and Opera and an incomplete putImageData impl for WebKit both blit in  
<2ms -- that's not slow,
it's certainly far faster than you're likely to be able to provide  
content.

If you're actually complaining about the time taken to fill the data  
array that's a different issue
entirely -- Opera does actually provide an ImageData constructor, and  
getImageData return
specialised objects, with a specialised array implementation, but when  
push comes to shove
the only real difference is when the bounds checking occurs (eg. on  
assignment to the data
array vs. during putImageData stage) but in my testing that's where  
most of the time is spent
in putImageData.

Editing the raw pixels in the canvas backing store is also not  
feasible as there would be too
many issues with implementation details (eg. the canvas in webkit is  
flipped, and i very much
doubt that that is the case for other engines, some engines use a  
premultiplied backing store,
some don't).

That said i would still very much like to have the ability to paint  
only a subregion of an ImageData
object.

--Oliver
Received on Friday, 1 February 2008 00:27:10 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:39 UTC