On Sun, 29 Nov 2009 06:21:45 +0100, Silvia Pfeiffer
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 your wiki page for clarifica
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
infr
Philip, all,
On Sun, Nov 29, 2009 at 9:37 PM, Philip Jägenstedt wrote:
> On Sun, 29 Nov 2009 06:21:45 +0100, Silvia Pfeiffer
> wrote:
>> My wasn't supposed to stay a JavaScript implementation. In
>> fact, it had the exact same purpose as your proposal: to
>> eventually be added into the HTML5
Philip Jägenstedt wrote:
On Thu, 26 Nov 2009 22:30:41 +0100, Tim van Oostrom
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 and element
On Sun, 29 Nov 2009 12:46:16 +0100, Tim van Oostrom wrote:
Philip Jägenstedt wrote:
On Thu, 26 Nov 2009 22:30:41 +0100, Tim van Oostrom
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 ja
Tim van Oostrom wrote:
Philip Jägenstedt wrote:
On Sun, 29 Nov 2009 12:46:16 +0100, Tim van Oostrom
wrote:
Philip Jägenstedt wrote:
On Thu, 26 Nov 2009 22:30:41 +0100, Tim van Oostrom
wrote:
Hi, I made a forumpost :
http://forums.whatwg.org/viewtopic.php?t=4176, concerning a
possible "
On Nov 28, 2009, at 10:09 PM, Boris Zbarsky wrote:
> This is not an issue at all; any XULRunner application can be run in Firefox
> directly (with the right command-line flags). I'm happy to profile whatever
> set of operations you want for you in Firefox if you send me step-by-step
> instruct
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 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 particula
On Sun, Nov 29, 2009 at 6:59 PM, Kenneth Russell wrote:
> On Sat, Nov 28, 2009 at 9:47 PM, Boris Zbarsky 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
>> usual "if it's an intege
On Sun, Nov 29, 2009 at 11:05 AM, Philip Taylor wrote:
> On Sun, Nov 29, 2009 at 6:59 PM, Kenneth Russell wrote:
>> On Sat, Nov 28, 2009 at 9:47 PM, Boris Zbarsky wrote:
>>> Are they even byte stores, necessarily? I know in Gecko imagedata is just a
>>> JS array at the moment; it stores each of
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 "no
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 ca
On Sun, 29 Nov 2009 14:28:05 +0100, Philip Jägenstedt
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 should
replace this
On Nov 29, 2009, at 10:59 AM, Kenneth Russell wrote:
> On Sat, Nov 28, 2009 at 9:47 PM, Boris Zbarsky 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
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/putImage
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 JavaScriptC
20 matches
Mail list logo
