The spec (http://www.khronos.org/registry/typedarray/specs/latest/) says "Constructors: None”, looks like FireFox is right, we should probably just remove this.
G. On Aug 14, 2013, at 12:34 AM, Filip Pizlo <fpi...@apple.com> wrote: > And on a similar note: ArrayBufferView. What's that all about? > > Previously, WebKit had ArrayBufferView as a prototype and constructor that > wasn't instantiable, allowing for things like: > > (new Int8Array() instanceof ArrayBufferView) === true > > but not: > > new ArrayBufferView() // error! > > Firefox has no notion of ArrayBufferView. I.e. you get a reference error if > you mention it. I tend to think that having ArrayBufferView as a JS-visible > concept is strange. > > -Filip > > > On Aug 14, 2013, at 12:31 AM, Jochen Eisinger <joc...@chromium.org> wrote: > >> Adding Dmitry who recently updated the V8/blink implementation. >> >> -jochen >> >> >> On Wed, Aug 14, 2013 at 9:19 AM, Filip Pizlo <fpi...@apple.com> wrote: >> What WebKit previously did: Uint8ClampedArray is a subtype of Uint8Array, >> i.e. Uint8ClampedArray.prototype.__proto__ === Uint8Array.prototype. >> >> I believe that Chrome still does what WebKit does. >> >> What Firefox does: Uint8ClampedArray is not a subtype of Uint8Array, i.e. >> Uint8ClampedArray.prototype.__proto__ === Object.prototype. >> >> What http://www.khronos.org/registry/typedarray/specs/latest/ says: >> Uint8ClampedArray implements ArrayBufferView; but that says nothing about >> its subtype relationship, or lack thereof, with Uint8Array. >> >> I prefer the Firefox semantics. Any objections? >> >> -Filip >> >> >> On Aug 13, 2013, at 11:19 AM, Filip Pizlo <fpi...@apple.com> wrote: >> >>> Hi everyone! >>> >>> For the past week or so I've been working on making typed arrays faster, >>> use less memory, and GC better. It involves moving typed arrays entirely >>> into JSC, and rewriting them so that they benefit from JSC object model >>> optimizations. >>> >>> Link: https://bugs.webkit.org/show_bug.cgi?id=119064 >>> >>> The short story is, if you're not on the Mac port, then I'll try to do my >>> best to make things work but I'm probably going to make some mistakes. I'm >>> probably about 48 hours away from landing this and I'll try to make myself >>> available to fix any fall-out. The things I'm most likely to get wrong >>> are: ensuring that the various code generators work on all build systems; >>> ensuring that the ~20-some files I've added and the ~20-sime files I've >>> deleted, are actually added/deleted correctly on all builds; and making >>> sure that some of the crazy template hacks that I've used work on all >>> compilers. >>> >>> Why this is all worth it: >>> >>> It makes typed arrays faster: you can now allocate typed arrays up to 8x >>> faster if they're small, and up to 6x faster if they're big. Neutering no >>> longer requires walking all worlds. Wrapping and unwrapping an array buffer >>> no longer requires hash look-ups for the normal world. And some other >>> stuff, too. >>> >>> It makes typed arrays use less memory: previously a typed array could use >>> as many as 7 objects for each allocation; at best you'd get 5 (JS array >>> buffer view wrapper, native array buffer view wrapper, weak handle to link >>> the two, native array buffer, native array buffer contents). Now, it takes >>> just 2 objects in the common case (JS array buffer view and a copy-space >>> backing store) and 3 in the case of large ones (JS array buffer view, weak >>> handle for a finalizer, and a malloc'd backing store). You'll still get >>> all of the crazy objects - at most 6 of them - if you use the full power of >>> typed array APIs. With all of this in place, a typed array carries only 32 >>> bytes of overhead on 64-bit systems and 20 bytes of overhead on 32-bit >>> systems. It was *a lot* more than that before. >>> >>> It makes typed arrays manage memory properly: previously the GC didn't know >>> that typed arrays use memory. So, although the GC could free the memory >>> that typed arrays used, it wouldn't kick in properly in some cases. See >>> https://bugs.webkit.org/show_bug.cgi?id=119049 and >>> https://bugs.webkit.org/show_bug.cgi?id=114824. This patch fixes these >>> issues comprehensively. >>> >>> It makes the code more hackable: previously any attempt to optimize any >>> typed array hack required grappling with binding code generation, layering >>> violations that exposed the typed arrays to JSC JITs despite not being >>> defined in JSC, and a grab-back of helper code that the bindings magically >>> invoked. There was a lot of duplicated code to deal with the various types >>> of typed arrays. Now, typed arrays are all templatized; you usually only >>> write a piece of code once thanks to the wonders of template polymorphism. >>> >>> This also fixes a bunch of semantics issues, with how typed array fields >>> work in JS and when/where exceptions ought to be thrown. In this regard, >>> I'm basically attempting to match Firefox behavior since that's where the >>> standards appear to be going. >>> >>> I hope that I get all of this to work on all platforms on the first try. >>> If I don't, I apologize in advance, and I'll try to be around to help the >>> fall-out. >>> >>> -Filip_______________________________________________ >>> webkit-dev mailing list >>> webkit-dev@lists.webkit.org >>> https://lists.webkit.org/mailman/listinfo/webkit-dev >> >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> https://lists.webkit.org/mailman/listinfo/webkit-dev > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
