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.
Related
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.
Right now I'm on a project that's moving video streams across RTMP using mostly ActionScript 3.0 (a little bit of 2.0 is used on the server side), and we already have functionality in place to throttle bandwidth usage for these video streams on the client level. However we're only doing that by calling the setQuality() method of class Camera, which affects every receiver of that video stream. Now though we really need a way to effectively set the bandwidth usage for individual receivers, but apparently VideoDisplay, NetStream, and NetConnection are all pretty much void of this sort of functionality. Is there not some decent way to do this in AS3? If there is a way, how? Thanks!
EDIT: For clarity let's say that the sender of the video stream has their Camera object's quality set to use 1 meg of bandwidth. How could I make a receiver of that stream only use half a meg of bandwidth to stream that video in without messing with the sender's 1 meg setting?
FMS just passes data received from publisher to the set of subscribers. It's doesn't change it (at least from the data point of view). What you require, though, is transcoding of the video stream being published according to subcriber needs.
Simple RTMP dosn't do that at all. I think there is a way to publish multiple streams for the same data using http streaming feature. But, in that case, the publisher would really be publishing multiple streams of the media to FMS.
I have a database of 3D models. I want user can rotate the model and view it in the web page.
So I have to implement an instant rendering algorithm for this.
A raytracing/raycasting method on CPU is preferred since the server has no GPU on it.
I understand that a primary-ray-only ray tracer with SSE and KD-Tree/BVH can be very fast. Besides, I want to add some GI effect(fake GI effect can be also OK for me, such as SSAO) in it.
How good can I achieve?
(some NPR rendering methods are also considerable)
In HTML5, you can render 3D objects with WebGL (an implementation of OpenGL) with some JavaScript. The problem is that WebGL is a client technology. Therefore, all the rendering is done by the browser.
There is one possible solution if you really want to distribute some logic on a server. You could use a server side language and send the vertices to the client through some database transactions. After, your website could make some AJAX calls to a server that would make certain operations within the server and return some vertices. The only problem is that this could require a lot of bandwidth.
Otherwise, another solution would be to use a tool such as Unity to create what you want. Then, you would need to embed the Unity Player in your web page.
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.
What I would like to do is create a canvas that will show a network map. It's not really a network map but in terms of explaining it the network map example works best to not bog you down with details that don't pertain to my question.
On the network map I want to display routes the traffic takes. These routes change in time, sometimes as frequently as multiple times per minute. On the server side I have a log file to which each route change is appended as it happens.
I know how to create the canvas, I know how to draw my routes onto the canvas.
Is it possible to have the server push an update to the canvas without requiring a page reload/refresh, essentially requiring no user interaction at all? The routes drawn just automagically change?
This would need to work on IIS so a jscript or .Net based solution would be necessary. I won't be able to install PHP, Python, Ruby etc.
Thanks in advance for any insights you can provide.
I recommend that you look at a WebSockets solution to push the information from the server to the client (JavaScript). When you receive the update you can update the canvas as required.
Technologies you should look at if your preferred server technology is .NET would be a service like Pusher, who I work for, and our .NET APIs which let you push updates to the client via our REST API.
If you would prefer to host your own realtime infrastructure then you could look at WebSync (which is actually a Comet technology) which integrates with IIS and also XSockets. There are also a number of realtime technologies on this guide which may interest you. If you've any further questions just let me know.
Server-Sent Events: http://www.html5rocks.com/en/tutorials/eventsource/basics
( Server-sent events is a technology for providing push notifications from a server to a browser client in the form of DOM events. The Server-Sent Events EventSource API is now being standardized as part of HTML5[1] by the W3C. )
Yes, I've done this before (with an ajax-based drawing application). It's very possible. Send packets of information via AJAX (JSON or something), interpret them, and draw them on the client's canvas element. This is trivial to design (and easy to implement using something like jQuery). It seems that you already figured out you need to have a server-side script that pushes information to a web page and a web page that actually draws stuff on the canvas. That's essentially all it is.