Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use OffscreenCanvas instead of --proxy-to-worker #13652

Open
janpaul123 opened this issue Mar 12, 2021 · 5 comments
Open

Use OffscreenCanvas instead of --proxy-to-worker #13652

janpaul123 opened this issue Mar 12, 2021 · 5 comments
Labels

Comments

@janpaul123
Copy link

janpaul123 commented Mar 12, 2021

I was trying to figure out how to get WORKERFS to work so I can read from File objects directly, and for that I needed my SDL application to run in a web worker. In order to do that I came across --proxy-to-worker, but ran into its limitations (e.g. it crashes on createVertexArray because getExtension('OES_vertex_array_object') is not implemented).

I was then wondering if --proxy-to-worker should be deprecated altogether, since we can now render to a WebGL OffscreenCanvas in a WebWorker directly. I'm still trying to figure out how to do this exactly, so maybe it's implemented already (-s PROXY_TO_PTHREAD?). In that case it might be good to update the documentation accordingly (and perhaps add a note to --proxy-to-worker that you shouldn't use it, and what the alternative is?). Thanks!!

@sbc100
Copy link
Collaborator

sbc100 commented Mar 12, 2021

I think --proxy-to-worker (AKA PROXY_TO_WORKER) has largely been replaced by PROXY_TO_PTHREAD these days.

We do still have support for it though and there is still some testing. The last time this came up I think perhaps @juj still had some valid use cases for it?

@janpaul123
Copy link
Author

janpaul123 commented Mar 12, 2021

Yeah, I spent some more time trying to figure out PROXY_TO_PTHREAD, and it looks like it hasn't been fully implemented for SDL yet, see e.g. emscripten-ports/SDL2#127 which is still open. So I don't think we can tell people to switch over from --proxy-to-worker quite yet.

It still might be worth adding a note in the docs at --proxy-to-worker, that PROXY_TO_PTHREAD might be preferable whenever possible, even if --proxy-to-worker doesn't get outright deprecated (if that's the direction things are going in). I'd be happy to make a little PR if people think this is a good idea.

@juj
Copy link
Collaborator

juj commented Mar 13, 2021

The last time this came up I think perhaps @juj still had some valid use cases for it?

I have actually never used --proxy-to-worker for anything. When I authored --proxy-to-pthread, I thought that would obsolete --proxy-to-worker, and on several occassions I have proposed for --proxy-to-worker to be removed, though @kripken has held on to it iiuc as he has dealt with users that have used --proxy-to-worker.

@kripken
Copy link
Member

kripken commented Mar 15, 2021

proxy-to-worker also does not require pthreads. It just proxies with postMessage basically, and it can proxy a single-threaded app, which can be useful.

(Perhaps when pthreads support on the web is ubiquitous that will not matter though.)

@stale
Copy link

stale bot commented Apr 16, 2022

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.

@stale stale bot added the wontfix label Apr 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants