great, thanks! § Richard Janicek <http://janicek.co> ¦ Clock2D.com<http://www.clock2d.com/> ¦ RetroPlay.co ¦ Chrome <https://chrome.google.com/webstore/search/Janicek>
On Sat, Jan 4, 2014 at 10:23 PM, Alon Zakai <[email protected]> wrote: > Yes, see in emcc where --proxy-to-worker is noticed. We set > PROXY_TO_WORKER which is defined in library_sdl.js. As a constant in the JS > environment at compile time, of course. To access it at runtime, you could > do {{{ PROXY_TO_WORKER }}} which would at compile time evaluate that. > > - Alon > > > > On Sat, Jan 4, 2014 at 1:54 PM, Richard Janicek <[email protected]> wrote: > >> I have audio proxy somewhat working in VICE.js now using proxying >> SDL_*Audio functions technique. I am working on cleaning things up. >> >> Is there a way to detect if `--proxy-to-worker` option is being used >> in `library_sdl.js` ? I created a global flag in `proxyWorker.js` but was >> wondering if something already exists. >> >> 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/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.
