It seems that we can not get sensor data in the web workers. I wonder the reason behind it. The use case is that I am thinking about getting geolocation data in the worker thread and only send the processed version to the main thread.
For GPS, this post says it is not supported in the worker thread (no reason is given). And I double checked it, navigator.geolocation is not supported in web workers. For accelerator and gyroscope, we have DeviceOrientationEvent and DeviceMotionEvent. But we need to use them through the window object, which is not available to the worker thread. The same situation applies to ambient light event.
So my questions are:
Why navigator.geolocation is not supported in web workers? I don't see any reason to prevent it in the worker thread. I think there should be no thread safety or security problems.
Does navigator.geolocation belong to navigator? This looks like a silly question. But I cannot find a good explanation online quickly... Web workers have access to the navigator object. And I am confused why navigation.geolocation is not supported.
Why don't we have raw sensor readings from accelerator and gyroscope? I understand that the abstracted event is useful. But there are cases we want to use the raw data for processing. I find that PhoneGap provides ways to access raw sensor data, e.g., through navigator.accelerometer. But my understanding is that such API does not belong to the standardized HTML specification.
What are the related design decisions to decide whether general sensor reading should be supported in the worker thread or not? General sensor reading support in HTML is currently shelved according to W3C Device APIs Working Group. Seeing current sensor support (gps, accelerator, gyro), I think we will get abstracted DOM events. And it is likely to have raw sensor data readings through the navigator object.
OK. After reading some Chromium code, I have the answer to my own question 2 now. I still have no answer to the other 3 questions...
Answer to question 2: Does navigator.geolocation belong to navigator?
navigator.geolocation belongs to navigator in the main thread only, but doesn't belong to navigator in the worker thread.
The main reason is that even though the navigator in worker thread looks exactly the same as the one in main thread, those two navigators have independent implementations on the C++ side. That is why navigator.geolocation is not supported in the worker thread.
The related code is in Navigator.idl and WorkerNavigator.idl in Chromium code. You can see that they are two independent interfaces in the .idl files. And they have independent implementations on the C++ side of the binding. Navigator is an attribute of DOMWindow, while WorkerNavigator is an attribute of WorkerGlobalScope.
However, on the JavaScript side, they have the same name: navigator. Well, I understand that the two navigators are in two different scopes, so there is no name conflict. But when I use the APIs in JavaScript, I expect similar behavior on both main and worker threads if they have the same name. That's how the ambiguity happens.
Related
I'm trying to find a way to launch a desktop application from a browser for os x. This application will be for customers only and should only be used for the hardware we provide.
I'd like to start off by saying I think this is a stupid idea. I'm being forced to use this approach by our CEO. I understand security policies could be an issue, as well as glaring vulnerabilities.
Since they can only run this on a single device I don't know that jws would be the right solution. I haven't used it but based on what I've read it doubles as a distribution method (which we don't want). If it were to be jws then it would have to some how have to recognize the device we provided them to ensure it is being placed on the appropriate hardware, possibly based on the serial # (which I don't believe you can get from the browser).
Additionally, the browser would call methods and pass arguments to the application.
Is this even possible? If so, what tool would you recommend? Again, I'm only the messenger for this terrible idea.
You probably have Chrome or Safari configured to handle http://<uri> URIs, but many other types exist. Have you ever seen custom URI schemes used like itunes://<uri>, steam://<uri>, or skype://<uri> ?
Just like for http, when your OS tries to fetch the resource, it will attempt to handle the request in the application that registered a handler for that scheme.
If that's the kind of thing you're looking for, this question has already been answered.
My suspicion is that you were unaware of the term. If that answer works for you, we can mark this question as a duplicate.
In complement to #naomik's answer (which I believe is the right one), there are projects like AppJS, Fluid or Electron which are pretty much willing to bring web based apps to the desktop.
For the matter of communicating the App and your browser (should I say your server?), you could use an approach of message queues and websockets to get there, surely, it is a huge effort of orchestration and workarounds but in the end it is possible to get you there.
(Posted on behalf of the OP).
This does not appear to be possible. If you are considering this please don't, there are better solutions. I have finally convinced my CEO to use Angular2 inside electron for example.
I have a web application which create a big image (30Mo) as a bufferArray inside a web worker.
I would like to return this image to the main thread.
Return the bufferArray via the postMessage method is very slow (5 secondes) and it freeze the UI.
postMessage(data);
So, I have looking for a library to compress the image but I'm only find library which use HTML5 canvas.
Because HTML5 canvas is forbidden is Web Worker, I'm asking if you have solution to this problem ?
My goal is to take more time in the Web Worker and reduce the transfer time.
Some browsers support transferable objects but to my knowledge not all of them.
Transferable objects are basically pointers to structures that you pass from main thread to worker and/or back. Using this methodology requires sightly different invocation of postMessage()
More of this is covered here
How about to increase the concurrent web workers threads pool?
Here is two great articles which cast some lights on how to use it:
http://www.smartjava.org/content/html5-easily-parallelize-jobs-using-web-workers-and-threadpool
http://typedarray.org/concurrency-in-javascript/
Here's how use the postMessage method :
postMessage(jsonObject, [jsonObject.data.buffer]);
The first argument is the same as usual.
The second must be an array of ArrayBuffer.
Still looking for image compression library with no use of HTML5 canvas.
How can I get data usage programmatically on my WP8? I found class DataUsage with properties BytesReceived and BytesSent. But on MSDN I found the following:
Remarks Windows Phone 8
This API is not implemented and will throw an exception if called.
Perhaps, somebody knows how can I get the traffic usage (for cellular/Wifi connection)?
Unfortunately, there's no API to get the overall traffic usage of the phone. Or at least, none available to third-party developers (there's probably some kind of internal API since Data Sense is able to display that information).
This is just out of curiosity, as I program games for a living, not web applications.
What is the reason that the Chrome extension API (chrome.* family) consists almost entirely of callback setters? I'm talking about this programming model that at first sight appears to be abusing closures:
// do something with the Tab object of an activated tab
chrome.tabs.onActivated.addListener(function (activeInfo) {
chrome.tabs.get(activeInfo.tabId, function(theTab) {
foo(theTab);
});
});
I'm used to having getters simply return the requested value and just find this interesting. Is this because all these methods (such as getLastFocused here) actually only schedule asynchronous tasks for the browser engine?
I was wondering something similar and came across a good explanation, maybe someone will find this useful as I did:
[The reason for using callbacks in the APIs] has to do with Google Chrome's multi-process architecture. Web pages and JavaScript run in processes which are not only separate from each other, but also from the main browser process which alone has the ability to do things like read & write to the local file system. This is an important security and stability feature for Google Chrome. If calls like this were synchronous, your extension would have to stop everything and wait for the browser process to respond to the request, all the while the user may be trying to interact with the UI of your extension which has become unresponsive. Using asynchronous APIs is more challenging, but it's in the service of the best user experience.
This is from the transcript of this video on the extension API design.
This is a combination of an event handler and some asynchronous actions. In addition, the way scoping works in javascript can be a bit iffy; using closures creates a reliable scope that allows data to be passed about that just couldn't be done in another manner.
From my perspective, one of the reasons, why most methods in the chrome.* APIs are asynchronous, is that extensions usually have to deal with the user interactions. Any asynchronous API in general leads to better application responsiveness. So, developers of the chrome.* APIs simply provide an easier way to write efficient extensions, that will not slow down Google Chrome, making users disappointed.
I opened this matrix multiplication benchmarks and my browser (Firefox 7.0.1) froze until the benchmarks finished (I opened the page in an old Asus EeePC 1000H).
I heard that web workers were invented to separate processing from displaying the web pages. Is it possible to make use of the Web Workers API to make WebGL not stall the whole web browser ?
For the sake of clarity: the benchmark that you linked to does not use WebGL at all. (I should know, I wrote it.) And in the case of that particular benchmark you absolutely could run it in a Web Worker now and it would be perfectly fine.
(Fun fact - Web Workers didn't support TypedArrays when the benchmark was built, and since most of the matrix libraries rely on that it was impractical to run it in a Worker at that time. That has since been fixed.)
Anyway, to answer your original question: No, WebGL cannot run in a worker. The core blocker to this is that in order to get a WebGL context you need to call getContext on a canvas element. Web Workers explicitly disallow DOM access (which is a good thing, BTW!) and as such you'll never be able to access WebGL from a worker.
But that's not as bad as you might think. For one, consider that most all 3D rendering is actually happening in a different thread anyway. Specifically, a whole bunch of threads running on your GPU. The only part the browser has in it is to tell your graphics driver "Hey! Start rendering some triangles using this data!" and then it moves on without waiting for the triangles to actually be rendered. As such, while the draw commands must be executed from the main process, the time it spends blocking that process is (usually) very little.
Of course, that's not what's going to eat up a bunch of your time if you were coding a realtime game. You've got animations, physics, AI, collision detection, pathfinding... there's a lot of non-graphical tasks involved that will eat your CPU alive if you let them. In some case (animation), it's usually just gobs and gobs of matrix math, just like the benchmark you linked to! Fortunately for us, however, that type of processing CAN be done in a Worker, and all we need to communicate back to the main thread is the data required to render the scene.
Yes, this introduces some challenges in terms of synchronization and data transfer, but on the whole it will be vastly preferable to locking up your browser while we try and simulate those 500 boxes colliding.
Yes, on Firefox!
https://hacks.mozilla.org/2016/01/webgl-off-the-main-thread/
We’re happy to announce WebGL in Web Workers in Firefox 44+! Using the new OffscreenCanvas API you can now create a WebGL context off of the main thread.
By default you can't use WebGL in a Web Worker as Toji explained.
You can check out WebGLWorker which is a library that lets you do WebGL stuff in a Web Worker, by transparently proxying commands to the main thread.
Here is a nice blog post that explains how it works.