There are other problems too, like supporting object instanceof float[] (or
even instanceof Object), not that you likely do a lot of things like that.
I had a patch once upon a time that would let you optionally use typed
arrays _or_ js lists as primitive arrays (except longs of course), but it
> The reason I'm asking is because Super-source solution can not change all
> "new int[...]" invocations in my program.
> As far as I understand, the SS solution can change some ArrayFactory and
> each time I need to use it I have to write ArrayFactory.createFloatArray.
> "new float[]" will
The reason I'm asking is because Super-source solution can not change all
"new int[...]" invocations in my program.
As far as I understand, the SS solution can change some ArrayFactory and
each time I need to use it I have to write ArrayFactory.createFloatArray.
"new float[]" will not be
> How can I personally patch the compiler to use Float32Array Int8Array,
> Int16Array, Int32Array, e,t,c ?
> Is it super-hard ?
> Is there a single place that generates new basic type array ?
>
I think easiest solution would be to implement an "optimization pass" on
the JavaScript AST. You
OK thanks.
How can I personally patch the compiler to use Float32Array Int8Array,
Int16Array, Int32Array, e,t,c ?
Is it super-hard ?
Is there a single place that generates new basic type array ?
If it is possible I could deploy the patched version to our company local
repository.
Thanks
> There is an ugly workaround (which breaks portability, yes I write
> portable client code (iOS, Android)):
>
To make it portable use GWT super source. So in your main code you create a
normal float array and in GWT super source you create the Float32Array
instead. Then you publish
Hi,
the problem is that it is too slow compare to Float32Array.
Especially it is super-slow it everything except chrome: FF, IE\EDGE.
More then that, it produce tonns of garbage (in FF and EDGE) working with
large images:
Here I wrote some float[] code to emulate water surface
