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]<javascript:>
> > 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]<javascript:>
>> > 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]<javascript:>
>>> > 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]<javascript:>
>>>> .
>>>> 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]<javascript:>
>>> .
>>> 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] <javascript:>.
>> 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.
