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/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.
