I will need to merge with the new ScriptProcessorNode updates and then I will submit a pull request.
Thanks, § Richard Janicek <http://janicek.co> ¦ Clock2D.com<http://www.clock2d.com/> ¦ RetroPlay.co ¦ Chrome <https://chrome.google.com/webstore/search/Janicek> On Tue, Feb 11, 2014 at 12:06 AM, Alon Zakai <[email protected]> wrote: > Sounds good (no pun intended ;) , please open a pull request to the > incoming branch and we can discuss details there. > > - Alon > > > > On Mon, Feb 10, 2014 at 5:49 PM, Richard Janicek <[email protected]> wrote: > >> Hello, >> >> I'm pretty happy with the sdl audio proxy I added to proxy to worker >> mode. I implemented it into VICE.js. Proxy to worker allows VICE to run a >> little closer to how it was designed and squeezes some extra performance >> out of the hardware, especially lower powered hardware. >> >> I tested with sdl_audio_beep.cpp and added a proxy to worker version of >> that test (test_sdl_audio_beeps_proxy). >> >> Here is the commit for your consideration: >> >> * SDL audio proxy >> commit<https://github.com/rjanicek/emscripten/commit/e3355d262064313ee60fbb7d1e238c247b9b0c90> >> >> * VICE.js demo without proxy to worker <http://tinyurl.com/ltjoau7> >> >> * VICE.js demo with proxy to worker <http://tinyurl.com/kyhxctt> >> >> >> Thank you, >> >> § Richard Janicek <http://janicek.co> ¦ Clock2D.com<http://www.clock2d.com/> >> ¦ RetroPlay.co ¦ Chrome<https://chrome.google.com/webstore/search/Janicek> >> >> >> On Sun, Jan 5, 2014 at 7:12 PM, Alon Zakai <[email protected]> wrote: >> >>> Yes, with a minimal testcase. >>> >>> - Alon >>> >>> >>> >>> On Sun, Jan 5, 2014 at 3:55 PM, Richard Janicek <[email protected]> wrote: >>> >>>> Hi Alon, >>>> >>>> `#if` pre-processor command inside `#include x.js` is not working. >>>> Should I file a bug? >>>> >>>> Thanks, >>>> >>>> § Richard Janicek <http://janicek.co> >>>> >>>> >>>> On Thu, Jan 2, 2014 at 8:39 PM, Alon Zakai <[email protected]>wrote: >>>> >>>>> I added an option now to do >>>>> >>>>> #include x.js >>>>> >>>>> in files like library_sdl.js, so you can include another file from >>>>> src/. Note though that you will need to manually include that file to >>>>> proxyClient.js, since that file is handled only be emcc. >>>>> >>>>> - Alon >>>>> >>>>> >>>>> >>>>> On Thu, Jan 2, 2014 at 4:00 PM, Richard Janicek <[email protected]>wrote: >>>>> >>>>>> Hi Alon, >>>>>> >>>>>> I am exploring the audio proxy options you suggested. First I tried >>>>>> to create shims for the Browser Audio classes. This approach was not >>>>>> practical for these reasons: >>>>>> * A large API needs to be proxied, lots of different Classes some >>>>>> vary by browser. >>>>>> * Managing all the audio object proxies (createBufferSource, >>>>>> createBuffer) is complicated. >>>>>> * Need to track references to proxied objects. >>>>>> * Determining when to free objects can be difficult. Objects can >>>>>> have references to each other. >>>>>> * `postMessage` communication would be chatty. >>>>>> >>>>>> Next I am trying to modify the C level calls, this seems more >>>>>> promising. You mentioned to replace MIX_* calls, however my application >>>>>> only uses the SDL_*Audio functions so I am working on those. I am >>>>>> planning >>>>>> on copying some parts of the SDL_*Audio functions to the proxyClient. >>>>>> This >>>>>> means there will be some duplicated code. I would prefer to avoid this if >>>>>> possible. >>>>>> >>>>>> My question: Is there a way to "include" a js file inside both >>>>>> library_sdl.js and proxyClient.js? This way I could isolate the shared >>>>>> code >>>>>> in one place and use it in both client and worker. >>>>>> >>>>>> Thank you! >>>>>> >>>>>> ~Richard Janicek >>>>>> >>>>>> On Monday, December 30, 2013 12:28:02 AM UTC-5, azakai wrote: >>>>>> >>>>>>> Ok, the main code is in src/proxy*.js. You can see how basic canvas >>>>>>> operations are forwarded there. >>>>>>> >>>>>>> The proxying there listens to DOM events and sends them over. For >>>>>>> SDL audio, there are a few options and I am not sure which is best. One >>>>>>> is >>>>>>> to proxy at the C level - replace MIX_* calls in the worker with >>>>>>> functions >>>>>>> that proxy over. Or, another is to proxy at the HTML Audio object, >>>>>>> replace >>>>>>> it with a shim that proxies. First step is to look at both of those >>>>>>> options, I think. >>>>>>> >>>>>>> - Alon >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sun, Dec 29, 2013 at 6:53 PM, Richard Janicek <[email protected]>wrote: >>>>>>> >>>>>>>> Any guidelines you could provide would be much appreciated. I will >>>>>>>> attempt to implement. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Sun, Dec 29, 2013 at 9:30 PM, Alon Zakai <[email protected]>wrote: >>>>>>>> >>>>>>>>> Yes, audio is possible as well. I don't have plans to work on this >>>>>>>>> myself but happy to give guidelines if anyone else wants to. >>>>>>>>> >>>>>>>>> - Alon >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sun, Dec 29, 2013 at 4:54 PM, Richard Janicek < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> I am testing --proxy-to-worker with VICE.js. Looks like it's >>>>>>>>>> getting +10% performance boost on Chrome. Very nice. >>>>>>>>>> >>>>>>>>>> Would it be possible to also proxy SDL audio? >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> ~Richard Janicek >>>>>>>>>> >>>>>>>>>> On Saturday, September 14, 2013 12:37:21 AM UTC-4, azakai wrote: >>>>>>>>>> >>>>>>>>>>> Close to that, yes. SDL_Delay can be implemented as a busy-wait >>>>>>>>>>> both on the main thread and in workers, but on the main thread _it >>>>>>>>>>> blocks >>>>>>>>>>> rendering_. On workers, it just blocks event handling; the worker >>>>>>>>>>> can still >>>>>>>>>>> send out paint events. >>>>>>>>>>> >>>>>>>>>>> This actually happens in Doom, it does screen wipe effects >>>>>>>>>>> synchronously. Those are not shown when running on the main thread, >>>>>>>>>>> because >>>>>>>>>>> nothing renders until the event loop is exited. But when running in >>>>>>>>>>> a >>>>>>>>>>> worker, they are shown perfectly. Input events can't be handled >>>>>>>>>>> during that >>>>>>>>>>> time, but in that case it doesn't matter - this might be a problem >>>>>>>>>>> in other >>>>>>>>>>> ones. >>>>>>>>>>> >>>>>>>>>>> I see it refresh the canvas very quickly, and this is without >>>>>>>>>>> much optimization (no typed array transfers, for example). No >>>>>>>>>>> reason it >>>>>>>>>>> can't be 60fps. >>>>>>>>>>> >>>>>>>>>>> - Alon >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Fri, Sep 13, 2013 at 6:34 PM, Richard Janicek < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> Oh wow, I think this may work for my app. Does this mean it >>>>>>>>>>>> is possible to allow synchronous blocking flow control in the >>>>>>>>>>>> worker thread >>>>>>>>>>>> (SDL_Delay) ? How fast can it refresh the canvas, is 60 fps >>>>>>>>>>>> possible? >>>>>>>>>>>> >>>>>>>>>>>> Thank you very much for this! >>>>>>>>>>>> >>>>>>>>>>>> § Richard Janicek <http://janicek.co> ¦ mappur<http://mappur.com> >>>>>>>>>>>> ¦ player <http://player.janicek.co/#player> ¦ >>>>>>>>>>>> clock2d<http://www.clock2d.com/> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Fri, Sep 13, 2013 at 8:47 PM, Alon Zakai <[email protected] >>>>>>>>>>>> > wrote: >>>>>>>>>>>> >>>>>>>>>>>>> If you use HTML canvas commands like lines, shapes, fills, >>>>>>>>>>>>> etc., all those need a 2D canvas context, and do not work in >>>>>>>>>>>>> workers (yet). >>>>>>>>>>>>> Right now what works is if all you do is render pixels to a >>>>>>>>>>>>> buffer and do >>>>>>>>>>>>> SDL_UnlockSurface to push them to the screen. >>>>>>>>>>>>> >>>>>>>>>>>>> But this is temporary, there is spec work going on to get >>>>>>>>>>>>> canvas and WebGL to workers, it will happen eventually, see e.g. >>>>>>>>>>>>> >>>>>>>>>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=801176 >>>>>>>>>>>>> >>>>>>>>>>>>> - Alon >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Fri, Sep 13, 2013 at 5:44 PM, Richard Janicek < >>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> What do you mean by "software renderer" ? My app >>>>>>>>>>>>>> (VICE.js<http://vice.janicek.co/>) >>>>>>>>>>>>>> renders frames to HTML canvas, does this mean I can't take >>>>>>>>>>>>>> advantage of >>>>>>>>>>>>>> this new technique? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thank you, >>>>>>>>>>>>>> >>>>>>>>>>>>>> § Richard Janicek <http://janicek.co> ¦ mappur<http://mappur.com> >>>>>>>>>>>>>> ¦ clock2d <http://www.clock2d.com/> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Fri, Sep 13, 2013 at 7:49 PM, Alon Zakai < >>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1. Proxing to/from a worker. With >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> emcc --proxy-to-worker >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> the compiler will generate html and js files, where the html >>>>>>>>>>>>>>> is a small shim that just proxies events to the js, which runs >>>>>>>>>>>>>>> in a worker, >>>>>>>>>>>>>>> and the js sends back the SDL screen which the html then >>>>>>>>>>>>>>> renders. So >>>>>>>>>>>>>>> basically this lets you run simple SDL apps in a worker, which >>>>>>>>>>>>>>> is usually >>>>>>>>>>>>>>> good for performance (doing less on the main thread). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This just supports code that does not use HTML canvas or >>>>>>>>>>>>>>> WebGL, because those don't run in workers in browsers (yet). So >>>>>>>>>>>>>>> it will >>>>>>>>>>>>>>> work right now for a software renderer, for example. I've >>>>>>>>>>>>>>> tested this on >>>>>>>>>>>>>>> Doom. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2. emscripten_async_load_script (see emscripten.h) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This loads a url into a newly-created HTML script element. >>>>>>>>>>>>>>> This is the most efficient way to load a new large amount of >>>>>>>>>>>>>>> code into your >>>>>>>>>>>>>>> app (emscripten_run_script converts binary to text, then evals, >>>>>>>>>>>>>>> which is >>>>>>>>>>>>>>> worse). It also integrates with the run dependencies system, >>>>>>>>>>>>>>> which means >>>>>>>>>>>>>>> that you can generate code to preload some files using the file >>>>>>>>>>>>>>> packager, >>>>>>>>>>>>>>> and emscripten_async_load_script of that will asynchronously >>>>>>>>>>>>>>> load the >>>>>>>>>>>>>>> script as well as fetch the file data and prepare it; the >>>>>>>>>>>>>>> callback will >>>>>>>>>>>>>>> happen when all the data is ready. This can be used e.g. to >>>>>>>>>>>>>>> load the next >>>>>>>>>>>>>>> level in your game, at the right time, and in general it can >>>>>>>>>>>>>>> make it easier >>>>>>>>>>>>>>> to avoid preloading everything at the beginning, which can >>>>>>>>>>>>>>> cause a >>>>>>>>>>>>>>> noticeable pause. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - Alon >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> 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 emscripten-discuss+unsubscribe >>>>>>>>>>>>>>> @googlegroups.com. >>>>>>>>>>>>>>> For more options, visit https://groups.google.com/grou >>>>>>>>>>>>>>> ps/opt_out. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> 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 emscripten-discuss+unsubscribe >>>>>>>>>>>>>> @googlegroups.com. >>>>>>>>>>>>>> For more options, visit https://groups.google.com/grou >>>>>>>>>>>>>> ps/opt_out. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> 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 emscripten-discuss+unsubscribe >>>>>>>>>>>>> @googlegroups.com. >>>>>>>>>>>>> For more options, visit https://groups.google.com/grou >>>>>>>>>>>>> ps/opt_out. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> 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 emscripten-discuss+unsubscribe >>>>>>>>>>>> @googlegroups.com. >>>>>>>>>>>> For more options, visit https://groups.google.com/grou >>>>>>>>>>>> ps/opt_out. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>> 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/groups/opt_out. >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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/groups/opt_out. >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> 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/groups/opt_out. >>>>>>>> >>>>>>> >>>>>>> -- >>>>>> 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/groups/opt_out. >>>>>> >>>>> >>>>> -- >>>>> 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/groups/opt_out. >>>>> >>>> >>>> -- >>>> 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/groups/opt_out. >>>> >>> >>> -- >>> 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/groups/opt_out. >>> >> >> -- >> 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/groups/opt_out. >> > > -- > 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/groups/opt_out. > -- 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/groups/opt_out.
