using webworkers for some cpu-intensive tasks

[vankasteelj]

Such as webtorrent, for example. Although we might be limited to webrtc connexions, which would be bad.

[vankasteelj]

from my quick tests, webtorrent doesn't seem to want to run in a worker.

• you can't require (fix: manually import require.js will enable that)
• you don't have access to window, webtorrent needs it
• you can't exchange objects with the main thread, postMessage only accepts strings and arrays (make json out of an object doesnt seem to work either, at least not if the object contains functions)

[xaiki]

i think @jaruba implemented something like that ?

[jaruba]

I did that with peerflix, not webtorrent, which doesn't need window and I only pass the magnet link to the worker

[vankasteelj]

you pass the magnet and get back the localhost url? yes that's what I wanted to do, but as I said, window is needed :/ Maybe checking with webtorrent directly. I vaguely remember reading an issue about it

[chtrinh]

In my PR (https://github.com/popcorn-official/popcorn-desktop/pull/474) I was able to fork a process and start up webtorrent there. I think instead of https://github.com/butterproject/butter-desktop/blob/master/src/app/lib/streamer.js#L285 resolving a url, the message passed back to the main thread can be the url. This way the UI (main thread) isn't locked up.

e.g.

this.worker.on('message', function(msg) {
   if(msg.action === 'url') {
       // creates the <video> here where the window DOM is present.
       this.waitForBuffer(msg.payload);
   }
}.bind(this));

[chtrinh]

I was able to make a branch that did the following:

1. Fork a process to run a Webtorrent Client.
2. Message broker class that did the message passing between forked process and Main UI
3. Player (videojs) access content via Http server from forked process

Noticeable:

1. There is a noticeable slow down for spinning and startup the web torrent client in a forked process. (I think we have to keep it alive after initialization of app and not destroy it after player closes.)
2. StreamInfo should split up to contain static parts that gets passed around from forked process to main process. e.g. title, quality, http por, etc., only once.
3. StreamInfo with dynamic parts are a bit tricky to deal with. e.g. download speed, upload. This gets laggy at times.
4. Code is ugly... probably not maintainable as of now.
5. UI/Main thread is snappier - but then again your player is loaded so not much UI there. a. However queuing and loading up several torrents in the background is possible and that could be a useful feature (e.g for series).

[xaiki]

it's #607

[xaiki]

1. let's spin up on init, after all we are a torrent streaming app, and we're going to use that for updater anyway. i'm not sure if we should spawn 1 webtorrent and add all to it, or spawn a worker by 'task', the second is probably easier to manage but heavier.

2. streamInfo should be split, no doubt about that !

3. delays in streaminfo reporting are not an issue, we should probably throttle updates though.

4. looks good to me =)

5. awesome ! i'm not sure though if we want many webtorrents or one that handles all. i guess the first is easier to manage while the second will require a registery.