Thank you, I will investigate those options. § Richard Janicek <http://janicek.co>
On Mon, Dec 30, 2013 at 12:28 AM, Alon Zakai <[email protected]> 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 [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.
