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