WebGL VS. Canvas 3D
Andor Salga | 7 November, 2009 | 20:33
I had the feeling after I did most of the porting from Canvas 3D to WebGL the performance dropped. To investigate, I ran our benchmark on two systems. The benchmark is simply a script which renders textured teapots in the canvas tag. On each machine I ran the benchmark using Firefox 3.5 with the Canvas 3D extension and then on Firefox 3.7a1pre which uses WebGL. Here are the results:
CDOT Desktop (New Zealand)
Windows XP Pro
Intel Core 2 Quad CPU @ 2.4GHz
3.24GB RAM
GeForce 8600 GT 512MB
Macbook Pro
OS X (10.5.8)
2.2GHz Intel Core 2 Duo
2GB DDR2 RAM
GeForce 8600M GT 128MB
The performance on the desktop is improved when using WebGL, but is reduced on the laptop. This could be happening for a variety of reasons, which I’ll need to carefully think over. But one important question which keeps bothering me is “Is this a fair test?”. One frame a second is terrible performance, but when you’re rendering 100 3D objects in a browser, it’s a bit unfair to just state that it’s too slow. I’d love to improve the performance so 100 teapots renders at 30FPS, but realistically that’s probably not going to happen. So, the question is by what factor can we speed up rendering? Frankly, I’m not entirely sure, but I’ll be taking a look at other WebGL demos and comparing to see what kind of performance they are able to provide. If anyone has ideas or suggestions, I’d love to hear them!
As a final note, I think to generate more accurate results, the benchmark needs to be modified or otherwise another more thorough benchmark needs to be created. One which runs at least a series of 100 tests. Each test could include an additional teapot to render. If this is done, graphing the results would much more meaningful. If anyone, especially OSD600 or DPS909 students is interested in doing this, let us know!
CDOT Desktop (New Zealand)
Windows XP Pro
Intel Core 2 Quad CPU @ 2.4GHz
3.24GB RAM
GeForce 8600 GT 512MB
| Teapots | Canvas 3D FPS | WebGL FPS | ||
| static | rotating | static | rotating | |
| 1 | 64 | 64 | 64 | 64 |
| 9 | 64 | 63 | 64 | 63 |
| 49 | 30 | 23 | 32 | 26 |
| 100 | 16 | 13 | 18 | 15 |
Macbook Pro
OS X (10.5.8)
2.2GHz Intel Core 2 Duo
2GB DDR2 RAM
GeForce 8600M GT 128MB
| Teapots | Canvas 3D FPS | WebGL FPS | ||
| static | rotating | static | rotating | |
| 1 | 55 | 55 | 43 | 39 |
| 9 | 16 | 15 | 11 | 9 |
| 49 | 4 | 3 | 2 | 2 |
| 100 | 2 | 2 | 1 | 1 |
The performance on the desktop is improved when using WebGL, but is reduced on the laptop. This could be happening for a variety of reasons, which I’ll need to carefully think over. But one important question which keeps bothering me is “Is this a fair test?”. One frame a second is terrible performance, but when you’re rendering 100 3D objects in a browser, it’s a bit unfair to just state that it’s too slow. I’d love to improve the performance so 100 teapots renders at 30FPS, but realistically that’s probably not going to happen. So, the question is by what factor can we speed up rendering? Frankly, I’m not entirely sure, but I’ll be taking a look at other WebGL demos and comparing to see what kind of performance they are able to provide. If anyone has ideas or suggestions, I’d love to hear them!
As a final note, I think to generate more accurate results, the benchmark needs to be modified or otherwise another more thorough benchmark needs to be created. One which runs at least a series of 100 tests. Each test could include an additional teapot to render. If this is done, graphing the results would much more meaningful. If anyone, especially OSD600 or DPS909 students is interested in doing this, let us know!
[...] from the original Canvas3D (WebGL’s predecessor). The latest news
WebGL around the net, 9 Nov 2009 - Learning WebGL | 9 November, 2009 | 11:34[...] from the original Canvas3D (WebGL’s predecessor). The latest news is that they have some speed comparisons (in terms of teapots per second
between the [...]
Hey... I noticed that my Macbook Pro has the same configuration
Arun Suresh | 3 December, 2009 | 23:13Hey…
I noticed that my Macbook Pro has the same configuration as your:
OS X (10.5.8)
2.2GHz Intel Core 2 Duo
2GB DDR2 RAM
GeForce 8600M GT 128MB
yet I am not able to get Minefield (v3.7a1) or WebKit (r51580)
to render anything for eg : http://www.peternitsch.net/demo/webgl/index.html
For Minefield.. i have flipped the “webgl.enabled_for_all_sites” and the “html5.enable” switch in about:config..
And for webkit, I have set the following switch.. “defaults write com.apple.Safari WebKitWebGLEnabled -bool YES”
For some reason.. nothing seems to work…
Could you please let me know if I am missing something ?
Thanks in advance
-Arun
NO status bar in the new firefox = now you
wap-tek | 25 December, 2010 | 5:51NO status bar in the new firefox = now you are blind ,
the status bar made it easy to tell if a site link
lied about where you were going and this was
just not coperate / advertizer friendly
webgl = require a beta browser = maybe see something
vrml/x3d = use a plugin or viewer
in any browser, = it worked over 10 years ago!
why cant mozilla just use
a generic vrml / x3d plugin
BUT make it FAULT TOLLERANT = as in
ignore the deliberate standards breaking
that the major players did 10 years ago
google , mozilla, and many other “good guys”
jumped the shark or drank the flavoraid
@wap-tek - sorry for the extremely delayed reply. Been
Cathy Leung | 3 January, 2011 | 13:21@wap-tek – sorry for the extremely delayed reply. Been taking a break with Christmas and all that going on. Firstly, I don’t think that webGL and X3D/VRML are really doing the same thing. From what I understood X3D/VRML is a high level declarative scene/model specification markup language. webGL on the otherhand is a low level api that allows web pages to make use of hardware accelerated 3D graphics on a person’s computer to render scenes but it is not in itself a scene specification language. In fact, x3dom (http://www.x3dom.org/) has been doing some work in using making use of webGL to render x3d scenes. It is plug-in free and works with any webGL enabled browser.
There is no status bar in Minefield because it is
Phreak Nation | 11 January, 2011 | 17:17There is no status bar in Minefield because it is a beta browser. Ever walk through a minefield? Not that easy to do. The status bar is not a big issue to me because I use the built in developer console which there you can explicitly track each file and where it is coming from.
Also you keep comparing a beta technology to something that has been around a while. This thing is BRAND new, and not even a standard. Hence why you have to use a beta browser. Also chrome is not a beta browser. Just have to pass an argument and you got it.
Also the reason this is being done is because with plugins come security risks and programming flaws. Always has been an issue with plugin vs native to browser. Also the browser does not monitor any plugin in the way you are wanting because not every plugin is made the same. That is going to be an impossibility.
You say they jumped the shark. I say they are ahead of the curve. Simply because this is beta. If you had an issue with it you have the option of not using it at all. All in all, beta means it is not fully functional and may have glitches, or features not readily available, and to use caution with the release. I refer back to my other comment from your other very similar post.
The reason ‘why cant’ is because it should be a standard feature in all browsers.