Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upMore robust webworker fallbacks #26
Comments
taisel
self-assigned this
Feb 1, 2016
taisel
added
enhancement
needed feature
browser compat
labels
Feb 1, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
taisel
Feb 4, 2016
Owner
Only issue now is that we have to user-agent sniff for the renderer thread creation still.
|
Only issue now is that we have to user-agent sniff for the renderer thread creation still. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
taisel
Feb 4, 2016
Owner
Probably should just make it a user setting whether or not to box the cpu thread in a separate thread. The user agent sniffing will fill in the default value for it, but it'll be user-overridable. The consequence of such is that if chrome hits the creation limit, the renderer will be on the same thread as the cpu thread, which will be in a separate thread from the main thread.
|
Probably should just make it a user setting whether or not to box the cpu thread in a separate thread. The user agent sniffing will fill in the default value for it, but it'll be user-overridable. The consequence of such is that if chrome hits the creation limit, the renderer will be on the same thread as the cpu thread, which will be in a separate thread from the main thread. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
Done. |
taisel commentedFeb 1, 2016
Some browsers like Google Chrome do not allow webworkers on localhost via opened file:///. Google Chrome also does not allow spawning webworkers inside of webworkers. We need to introduce proper code flow that isn't hacky to handle these cases.