W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2009

[whatwg] Canvas pixel manipulation and performance

From: Kenneth Russell <kbr@google.com>
Date: Fri, 4 Dec 2009 17:10:01 -0800
Message-ID: <921bb10912041710s227c2279l5027c0d454d43a42@mail.gmail.com>
On Fri, Dec 4, 2009 at 9:30 AM, Jason Oster <parasyte at kodewerx.org> wrote:
> I guess this suggestion to access the full pixel data in a single array
> element has fallen by the wayside. ?Are there any direct objections to
> including additional API to allow this kind of behavior? ?It seems most
> developers believe it would be unnecessary, but I haven't heard much in the
> way of reasoning (technical nor personal).
>
> I cannot comment on the "typical uses" of accessing pixel data from script;
> if it is [in general] more important to have each of the R,G,B,A components
> separated for script access, or not. ?But for cases involving indexed
> palettes, having the ability to directly treat each pixel as a single
> property is very much desired.
>
> It is not going to provide a huge boost in performance. ?At worst, it will
> help make code cleaner. ?But at best, it will do that and [slightly?] reduce
> the performance penalty of reading/writing 3 superfluous (in my eyes) array
> accesses. ?The only negative aspect I can think of with additional API
> functions is the introduction of new developer confusion; "Which one do I
> use?"

I think you'd get more traction if you had performance measurements;
minimally, profiles showing that this is hot in your current
application. Ideally, you could do a prototype in one of the browsers
supporting WebGL which exposes the ImageData's backing store as a
WebGLUnsignedIntArray. If this showed a significant speedup it would
provide strong motivation.

-Ken
Received on Friday, 4 December 2009 17:10:01 UTC

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