offscreen-canvas | move Three.js/WebGL/2D canvas | Graphics library
kandi X-RAY | offscreen-canvas Summary
kandi X-RAY | offscreen-canvas Summary
JS polyfill (375 bytes) for OffscreenCanvas to move Three.js, WebGL or 2D canvas to Web Worker. It will improve performance in Chrome and will load worker by
Support
Quality
Security
License
Reuse
Top functions reviewed by kandi - BETA
Currently covering the most popular Java, JavaScript and Python libraries. See a Sample of offscreen-canvas
offscreen-canvas Key Features
offscreen-canvas Examples and Code Snippets
Community Discussions
Trending Discussions on offscreen-canvas
QUESTION
I am trying to implement a in browser raster drawing plugin for the leaflet library that that extends the leaflets GridLayer api. Essentially for every tile there is function createTile
that returns a canvas with some drawing on it. and leaflet shows the tile in correct position.
ANSWER
Answered 2021-May-16 at 01:48This a known bug: https://crbug.com/1202481
The issue appears when too many OffscreenCanvases are sent to the Worker serially.
The workaround is then to batch send all these OffscreenCanvases in a single call to postMessage()
.
In your code you could achieve this by storing all the objects to be sent and use a simple debouncing strategy using a 0 timeout to send them all at once:
QUESTION
I am attempting to move a Three.js project to TypeScript. When I tried top compile it I would get an error referenced in this issue on the Three.js repo:
https://github.com/mrdoob/three.js/issues/17698
Following those steps I installed @types/offscreencanvas
as well as edited my tsconfig.json, but now I get this output when trying to run tsc
:
ANSWER
Answered 2020-Jan-16 at 09:02As per my comment to your question
This seems to be a TypeScript version problem, but the version in your package.json
seems to be correct. Have you tried to run this from a script
within your package.json
, in stead of through your terminal?
QUESTION
I'm new to web development, so this might be a dumb question. Please let me know if it's already answered:)
According to MDN web docs' page for OffscreenCanvas
, currently, the API only supports WebGL context only. (Maybe it just means the worker support for OffscreenCanvas
' 2d context is not implemented, but we can still use it on the main thread?)
Note: This API is currently implemented for WebGL1 and WebGL2 contexts only. See bug 801176 for Canvas 2D API support from workers.
But when I read the HTML Specs for OffscreenCanvas
, the 2d context is supported.
enum OffscreenRenderingContextType { "2d", "webgl" };
I suspect the second one is only a proposal for what OffscreenCanvas
should support, and the first is what is actually supported. Is my understanding correct? If so, how could I know whether a specific browser supports the 2d context for OffscreenCanvas
, like Chromium?
What makes me even more confused is people called the regular canvas
an offscreenCanvas
, and get a 2d context from it (example1, example2). But I think in this case, they are just referring a regular canvas which is not attached to DOM, other than the OffscreenCanvas
I like to research on.
ANSWER
Answered 2017-Oct-17 at 23:56I suspect the second one is only a proposal for what
OffscreenCanvas
should support, and the first is what is actually supported. Is my understanding correct?
Correct, the WHATWG spec is the standard that browsers should support. The reason Firefox's bug #801176 exists is because Firefox falls short of the requirements of the WHATWG specification in this area.
What makes me even more confused is people called the regular
canvas
anoffscreenCanvas
These are simply variables called offscreenCanvas
which hold a normal canvas. You can name your variables anything; these authors chose a descriptive name for a canvas that is not currently rendered on the screen.
QUESTION
(New to OpenGL / Emscripten)
For a stock trading client application I'm building there is the need of 40+ open charts. About 50% of them being in some sort of 'Free draw' state, meaning they show candlesticks plus other lines/arrows/images etc.
After trying a lot of options the last few months, here is what it comes down to.
- HighCharts: Easy but slow;
- CanvasJS: Faster but not fast enough
- WebAssembly + OpenGL: A lot faster, but a lot of work (still worth it)
I bootstrap a single WebAssembly app instance, and call functions on it to let C++ create charts with OpenGL, that maps to WebGL(2). It all works fine.
The reason I go for (WebAssembly + OpenGL) -> Emscripten, is because there is a lot of number crunching, and c++ suits that job fine as well :)
Problem is WebGL has a context limit of about 10 in Chrome(59). So having 40-100 WebGL context (Charts) is not a smart idea, also my guts tell me its a waste of OpenGL resources to have so many context that are almost always output as static images, unless you scroll the chart etc.
Does anyone have good experience with rendering a single OpenGL context to a random canvas element (or any other element, doesn't really matter)?
My thought are as follow:
- Start c++ OpenGL with an offscreen canvas in another thread, https://github.com/OleksandrChekhovskyi/emscripten-offscreen-canvas-test/blob/master/main.c#L35
- Javascript tells c++ to render a graph
- share/render the OpenGL backbuffer with JS through shared Uint8Array... SharedArrayBuffers gets filled by C++ in JS Worker thread and the main (render) thread only reads/transpiles to write image to canvas/html element.
I can't seem of any other way to not create many OpenGL contexts.
Question is: How performant will it be to do it like this, and basically copy over the OpenGL buffer to Javascript etc? It it far off track?
Thanks
p.s. bottom graphs (with red wave line) are now rendered by WebAssembly and OpenGL (GLFW etc)
------ UPDATE -----
Option 2: Always render to same Canvas, and use JS to copy context of canvas to another canvas (but it will probably be erased if the context updates..)
...ANSWER
Answered 2017-Jul-23 at 22:07So, after building some more I found a fast solution.
Im using just 1 context (GLFW) and trigger a C++ function through JS to render the chart, once done c++ signals back to JS using EM_ASM_ with the corresponding Chart ID to render the result (image) to its destination canvas width:
Community Discussions, Code Snippets contain sources that include Stack Exchange Network
Vulnerabilities
No vulnerabilities reported
Install offscreen-canvas
Support
Reuse Trending Solutions
Find, review, and download reusable Libraries, Code Snippets, Cloud APIs from over 650 million Knowledge Items
Find more librariesStay Updated
Subscribe to our newsletter for trending solutions and developer bootcamps
Share this Page