On Thu, 26 Nov 2009, Jason Oster wrote:
I've been using canvas to draw pixel art (NES/SNES game screens and
sprites) similar to what an emulator would do. Doing this kind of
drawing requires direct access to the pixel buffer.
My problem with the canvas spec (as it is now) is that it
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
On Fri, Dec 4, 2009 at 9:30 AM, Jason Oster paras...@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
On Dec 4, 2009, at 6:10 PM, Kenneth Russell wrote:
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
On Mon, Nov 30, 2009 at 4:46 PM, Kenneth Russell k...@google.com wrote:
CanvasPixelArray specifies that values greater than 255, including
+inf, are clamped to 255 and values less than 0, including -inf, are
clamped to zero. WebGLUnsignedByteArray (as people will see in the
WebGL draft spec
On Mon, 30 Nov 2009 19:31:53 +0100, Philip Taylor
excors+wha...@gmail.com wrote:
But it looks like the spec changed since I last looked, and the setter
takes an 'octet' argument, so I think the conversion should happen as
per http://dev.w3.org/2006/webapi/WebIDL/#es-octet and
CanvasPixelArray
I have to wonder if it's worth trying to micro-optimize web APIs like
this. Your suggestions will squeeze out only a small amount of
additional performance - the goals will get a bit higher and we'll be
back at square one.
I know NativeClient isn't a proposed spec or standardised piece of web
On Nov 29, 2009, at 4:19 AM, Mike Hearn wrote:
I have to wonder if it's worth trying to micro-optimize web APIs like
this. Your suggestions will squeeze out only a small amount of
additional performance - the goals will get a bit higher and we'll be
back at square one.
I've always imagined
That's one way to get a healthy performance boost (typically)
but where does the web developer stand in this work? Are
you suggesting native code should replace JavaScript?
For code where performance is critical (like complex animation code) yes.
Don't get me wrong, I'm all for better
On Sat, Nov 28, 2009 at 9:47 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/29/09 12:15 AM, Kenneth Russell wrote:
I assume you meant JS bitwise operators? Do we have any indication that
this would be faster than four array property sets? The bitwise ops in
JS
are not necessarily
On Sun, Nov 29, 2009 at 6:59 PM, Kenneth Russell k...@google.com wrote:
On Sat, Nov 28, 2009 at 9:47 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Are they even byte stores, necessarily? I know in Gecko imagedata is just a
JS array at the moment; it stores each of R,G,B,A as a JS Number (with the
On Sun, Nov 29, 2009 at 11:05 AM, Philip Taylor excors+wha...@gmail.com wrote:
On Sun, Nov 29, 2009 at 6:59 PM, Kenneth Russell k...@google.com wrote:
On Sat, Nov 28, 2009 at 9:47 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Are they even byte stores, necessarily? I know in Gecko imagedata is
On 11/29/09 1:20 PM, Jason Oster wrote:
Changeset 2b56c4771d5c reduced the number of pixel array elements
accessed by caching the 256px x 256px rooms within the stage map, and
passing the cached rooms to putImageData().
As opposed to doing what before the change?
The previous code used a
The patch changed something like this:
for (y in canvasHeight) {
for (x in canvasWidth) {
putPixel();
}
}
To something like this:
for (y in roomHeight) {
for (x in roomWidth) {
putPixel();
}
}
for (rooms_y in canvasHeight) {
for (rooms_x in canvasWidth) {
putRoom();
}
}
On 11/29/09 3:33 PM, Jason Oster wrote:
It might be important to note that this.fgmap.render() method also does some
tile decoding (to convert the SNES tile format into a usable bitmap), and
caches the results.
Does that make more sense? I know it is difficult to follow unfamiliar code,
but
On Nov 29, 2009, at 1:57 PM, Boris Zbarsky wrote:
So the new code has to do about half as much tile decoding, as well as half
the number of imagedata[n] sets? Or was the decoding already being cached?
Decoded tiles were already cached. It actually builds MORE tile caches now,
though: one
On Nov 29, 2009, at 10:59 AM, Kenneth Russell wrote:
On Sat, Nov 28, 2009 at 9:47 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/29/09 12:15 AM, Kenneth Russell wrote:
I assume you meant JS bitwise operators? Do we have any indication that
this would be faster than four array property
On 11/29/09 11:22 PM, Oliver Hunt wrote:
The CanvasPixelArray implementation in WebKit has always matched the
spec and been a clamping bytearray, eg. one byte per channel, per
pixel.
I assume you mean the spec as it is now and not the spec as it was
when Gecko implemented get/putImageData?
On 11/29/09 11:22 PM, Oliver Hunt wrote:
I don't know where you're getting that idea from -- the clamping semantics for
CanvasPixelArray and WebGLUnsignedByteArray are identical.
Perhaps Kenneth included the rounding behavior (which seems to be
different to me from a brief look at
My apologies for the direct reply, Oliver. This was meant to go back to the
list:
On Nov 26, 2009, at 3:35 PM, Oliver Hunt wrote:
WebGL has completely different constraints to that of the 2d canvas -- when
the developer provides resources to GL the developer has to provide a myriad
of
On Sat, Nov 28, 2009 at 12:44 PM, Jason Oster paras...@kodewerx.org wrote:
Once again, I agree. My confusion on the type-specific arrays for WebGL is
that they were specific and general enough to use in other cases. If they
should not be used in 2D canvas implementations (or elsewhere) then
On 11/28/09 11:42 PM, Kenneth Russell wrote:
From a technical standpoint, it would be feasible to use the
WebGLUnsignedIntArray to access the Canvas's pixel data, and
assemble RGBA pixels into integer values using just JavaScript logical
operators.
I assume you meant JS bitwise operators? Do
On 11/28/09 3:44 PM, Jason Oster wrote:
The trouble with profiling my project is that it is a XULRunner
application, and does not run directly in web browsers as-is.
This is not an issue at all; any XULRunner application can be run in
Firefox directly (with the right command-line flags). I'm
On Sat, Nov 28, 2009 at 9:00 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/28/09 11:42 PM, Kenneth Russell wrote:
From a technical standpoint, it would be feasible to use the
WebGLUnsignedIntArray to access the Canvas's pixel data, and
assemble RGBA pixels into integer values using just
On 11/29/09 12:15 AM, Kenneth Russell wrote:
I assume you meant JS bitwise operators? Do we have any indication that
this would be faster than four array property sets? The bitwise ops in JS
are not necessarily particulary fast.
Yes, that's what I meant. I don't have any data on whether this
Hello Group,
I've been using canvas to draw pixel art (NES/SNES game screens and sprites)
similar to what an emulator would do. Doing this kind of drawing requires
direct access to the pixel buffer.
My problem with the canvas spec (as it is now) is that it tends to artificially
bounds pixel
On Nov 26, 2009, at 11:45 AM, Jason Oster wrote:
Hello Group,
I've been using canvas to draw pixel art (NES/SNES game screens and sprites)
similar to what an emulator would do. Doing this kind of drawing requires
direct access to the pixel buffer.
My problem with the canvas spec (as
27 matches
Mail list logo
