If I wanted to make a simulated boids experiment in either of the technologies, what limitations would I be under.
For example I have a boids simulation working in canvas with 100,000 particles but I am unable to work with a million as the browser crashes. This may be possible in WebGL with hardware acceleration.
So what limitations do these 2 technologies have with complex scenes?
The limitations of the graphics card apply to WebGL as well of course, there is little a browser can do to compensate those. For example, I noticed that WebGL samples with the texture size 4000x4000 don't work with my (on-board) graphics chip. Animating a large number of objects will likely overburden low-end graphics cards as well.
Related
My app draws same figure on the canvas multiple times. We figured out that we could draw it once on the hidden canvas and them just copy it to the target canvas. I am doing some perf comparison. And I am facing some weirdness that I can't explain.
Here it is in a nutshell: I have a test with two canvases of the same size. In the first canvas I draw figures multiple times. On the second: I draw on the hidden canvas first, then I copy it into visible canvas. The result should be the same.
Here is the fun part: Approach with hidden canvas works fine with size of the canvas 400x164. It is 60% faster that drawing each figure separately.
But once I increase size by once pixel to 400x165 - bam! Stamping is 60% slower in Chrome. In IE it is still faster (ask me how I found out that 164-165 threshold).
Here are the links to JsPerf tests:
size 400x165: http://jsperf.com/draw-vs-stamping/7
size 400x164: http://jsperf.com/draw-vs-stamping/8
Chrome 46.0.2490.80 32-bit on Windows Server 2008 R2 / 7 64-bit
Any help is appreciated.
The answer is this and it is unfortunately stupid. I've been baffled by this for years. Your question helped me find the answer.
If and only if a canvas contains >= 60,000 pixels, will Chrome allow hardware acceleration.
I had a 200x200 mini-map sitting ontop of a webgl app. The webgl app would be rendering 150,000 polygons no problem at 60fps. Once the player began moving, the framerate would drop to ~30fps. Disabling the minimap would keep things at a smooth 60fps. I was surprised my tiny little super basic minimap would cause such a massive hit.
After searching on SO for a solution (and not really finding one), I began playing with the posted jsfiddles. Canvas size seemed to make all the difference. In one particular fiddle (from HTML5 drawImage slow on Chrome), I tried a size of 256x256 (area of 65,536), ran terribly. Tried 257x257 (area of 66,049) ran roughly 6x faster...
So I tried my minimap at 257x257 (used CSS zoom to shrink it down to the appearance of original size). Ran great, almost 0 performance hit when moving.
So there it is. Google chose a threshold of 60,000 pixels in order for hardware acceleration to kick in.
Annoying.
Version 63.0.3239.84 (Official Build) (64-bit)
Right now I'm testing on an Iphone 5 and everytime I add hardware acceleration (translatez(0)) on an element it seems to dramatically increase the performance while I can't figure out anything negative.
What are the disadvantages of putting all elements into hardware accelerated mode?
I noticed some z-ordering issues between hardware- and non-hardware accelerated elements. What other disadvantages should I pay attention to?
How is this with other devices and browser, like Android or Windows Phone?
I guess the answer to this question will follow from the answer above, but why isn't everything harware accelerated by default?
I had 2 times a problem with the hardware acceleration.
First in Firefox, that just doesn't show radial gradients (on some computers).
And once in Android Webview, where I got one some devices flickering and slowdowns.
So, my experiences with hardware acceleration: it's sometime just more error-prone.
One common bug I have seen when enabling "hardware acceleration" for elements that might contain a lot of children or occupy big portion of the screen is that some browsers might not render it at all leaving you with big white spot in the middle of your screen.
I have seen this bug mostly as a result of optimization of a responsive web page, where everything works flawless on small screen and then it does not on desktop Windows with Chrome for instance. I think this depends on OS and graphics adapter, but I have never dig into it much more. The solution usually is to narrow down the usage of hardware acceleration just to the portions of DOM you really need to.
I read an article saying it is best to use img control on mobile rather than use the canvas control.
Is this true as i cannot tell any differences.
You'll have to test on your own device with your own code.
In general canvas is programmatically intensive and therefore will be slower on devices (like mobile) that are less-powerful.
In addition, desktop devices always (almost always) have a GPU which the native canvas element will use to speed its calculations and display.
In my own experience, computationally intensive canvas apps are slower (often much slower) on mobile than desktop.
If your design allows you to use a static image instead of a canvas on mobile, then use the static image.
I am using HTML 5 canvas for drawing image and drawing annotations on that using paper.js.
I am trying to implement zooming functionality for Canvas. For this I am using scale function for that. As user try to do zoom then first i scale the canvas and then redraw the content.
But suppose if, there is much content on the Canvas, then it make slow to the process. It takes some while to render.
What can I do for this ?? Please suggest me feasible solution.
you can try with WEBGL rendering , WebGL is hardware accelerated so smoother operations than canvas. Three.js library provides webGL rendering option , latest browser version supports it.
Vector graphics like SVG opposed to raster graphics like PNG still look nice when scaling a web page. With the wide use of mobile devices this is a great advantage of vector graphics. But is there any performance decrease also?