[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] WebGL bufferSubData lacks "size" parameter

Gregg, you're not incorrect about the implicit garbage that can be
created by numerical operations in JavaScript. Mozilla's SpiderMonkey
and Apple's JavaScriptCore engines represent all values as forms of
64-bit doubles [1,2], which has the advantage that primitive
mathematical operations do not create garbage, but the disadvantage of
increased heap size -- all fields of all objects are 64 bits in size.
In order to keep heap sizes smaller, Google's V8 engine does not do
this, but the new Crankshaft compiler can optimize away heap
allocation of double values within large bodies of compiled code, and,
I believe, during stores to some arrays as well as typed arrays.

Regarding the current topic, echoing Chris's request above, please
produce a real-world test case that demonstrates a performance problem
with the current WebGL API structure. I dispute the claim that the
current API structure imposes a performance limitation on well-written


[1] http://bugsalert.com/Robert-Sayre-Mozillas-JavaScript-Representation_51129.html
[2] http://hacks.mozilla.org/category/jagermonkey/as/complete/
[3] http://es-la.facebook.com/note.php?note_id=10150254679701440&comments

On Wed, Jan 11, 2012 at 10:53 PM, Gregg Tavares (wrk) <gman@google.com> wrote:
> Okay, egg on my face yet again.
> Someone once told everything in JavaScript is an object
> Someone else once told me adding 2 numbers generates a new object.
> I believed them until today.
> The truth is more complicated
> http://www.2ality.com/2011/03/javascript-values-not-everything-is.html

You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl