On Sun, 29 Nov 2009 06:21:45 +0100, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
Philip,
It's great to see further specifications come up around captions. I do
think we need these to make progress and come to a specification that
we can all agree on.
I just wanted to add a comment on
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
Philip, all,
On Sun, Nov 29, 2009 at 9:37 PM, Philip Jägenstedt phil...@opera.com wrote:
On Sun, 29 Nov 2009 06:21:45 +0100, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
My itext wasn't supposed to stay a JavaScript implementation. In
fact, it had the exact same purpose as your ovelay
Philip Jägenstedt wrote:
On Thu, 26 Nov 2009 22:30:41 +0100, Tim van Oostrom t...@depulz.nl
wrote:
Hi, I made a forumpost :
http://forums.whatwg.org/viewtopic.php?t=4176, concerning a possible
microdata specification bug and a bug in the james.html5.org
microdata extractor.
Comes down to
On Sun, 29 Nov 2009 12:46:16 +0100, Tim van Oostrom t...@depulz.nl wrote:
Philip Jägenstedt wrote:
On Thu, 26 Nov 2009 22:30:41 +0100, Tim van Oostrom t...@depulz.nl
wrote:
Hi, I made a forumpost :
http://forums.whatwg.org/viewtopic.php?t=4176, concerning a possible
microdata
Tim van Oostrom wrote:
Philip Jägenstedt wrote:
On Sun, 29 Nov 2009 12:46:16 +0100, Tim van Oostrom t...@depulz.nl
wrote:
Philip Jägenstedt wrote:
On Thu, 26 Nov 2009 22:30:41 +0100, Tim van Oostrom t...@depulz.nl
wrote:
Hi, I made a forumpost :
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 Sun, 29 Nov 2009 14:28:05 +0100, Philip Jägenstedt phil...@opera.com
wrote:
Now, back to the problem of one property, multiple items. The algorithm
for finding the properties of an item [2] is an attempt at optimizing
the search for properties starting at an item element. I think we
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
19 matches
Mail list logo
