While testing the iOS 10.3 beta, I found that like Safari Technology Preview on desktop, it supports SharedArrayBuffer and can run emscripten pthreads code successfully.
I tested on an iPad Air, which has a dual-core 64-bit processor but only 1G of RAM. It seems to work well with both cores, showing good speed improvements for ogv.js's VP8 decoding on suitably-encoded files, but has serious limitations that may be related to code size. Pthreads mode means my video decode module is loaded 3 or 5 times: once on the main thread, then in a worker for each core (thus 3 on the iPad, with two cores), plus the single-threaded audio decoder as a separate module in another worker. For VP8/Vorbis it works, but for VP9/Opus the decoder modules are larger and more complex, and it seem like one module ends up not fully compiled -- either the video becomes too slow from one of its threads, or the audio ends up too slow. I can't successfully get threaded VP9/Opus decoding working on the iPad. I suspect that the compiled code cache is limited to a total size for all threads, or similar limitation. Don't know whether that size is the same for all iOS devices or is increased for those with more memory... In theory once WebAssembly gets threading support it should be more amenable to this sort of situation, since you can precompile a module and send it into the workers -- that should be more memory-efficient and have faster startup. -- brion -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
