WebGL around the net, 3 March 2011

You can leave a response, or trackback from your own site.

9 Responses to “WebGL around the net, 3 March 2011”

  1. Hi Giles,

    Thanks for the links. ChemDoodle slowness in Chrome is not caused by anti-aliasing. Both WebKit and FF4 work perfectly. There is actually a severe issue with Chrome, where WebGL performance degrades when multiple geometries are rendered. For now, our belief is that Chrome is not WebGL functional (also causes crashes on Mac when a computer returns from sleep with a WebGL application open).

    Our recommendation is that users uninstall Google Chrome and instead use WebKit and FF4 to view WebGL demos. At least, until the Chrome team fixes their browser.

    You can follow the bug report here: http://code.google.com/p/chromium/issues/detail?id=74526

  2. giles says:

    Hi Kevin,

    Thanks for the update, you’re quite right — I put that in a while back, before you’d told me that it wasn’t anti-aliasing. I’ve fixed the post.



  3. Bo says:

    Kevin: I really don’t want to teach you how to program, but if you care to do a little bit of profiling, you will find out that your program spends more than 50% of CPU time calling one single function: getUniformLocation. It’s amateurish to point fingers to others while you can easily fix the performance issue yourself, i.e. caching location value

  4. Bo,

    First, thank you for taking the time to look into my issue. I appreciate that and your suggestion.

    Your solution does relieve the issue, but it does not cure it. Caching values improves performance greatly for parameters like color, but for the large number of atoms and bonds we render, the true bottleneck comes from setting the model view matrix (uniformMatrix4fv). For each atom there is 1 geometry and for each bond there are 2 (one color for each side). Each geometry requires its own unique model view matrix, and therefore caching is not possible. That being said, you may know some techniques I do not, and I would be more than glad to hear them.

    The true issue comes down to browser performance. Surely, Chrome has an issue when WebKit and FF4 can render thousands of geometries smoothly (regardless of caching), while Chrome slows to a crawl. Please do not get me wrong, I am a huge fan of Google Chrome and recommend it over all browsers on Windows/Linux for our 2D components. The Chrome developer team is also incredibly talented and I am sure these performance issues will be fixed. I am more than happy to help discover these issues and push towards a solution.

    I will append the bug report with this additional information.

  5. Bo says:

    Ok, maybe I was a bit harsh, sorry about that. I’ve come up with a good idea to solve your problem. Instead of update matrix for each individual atom, you give them Identity world matrix and a defined View-Projection matrix. Then you pass Atom position as Vertex Uniform and transform them in the Vertex Shader. I’ve done that to my asteroid rendering code and I can render up to 10000 asteroids and still get 60 FPS. Try it, you won’t be disappointed.

  6. aa says:

    Demo’s from Robert Schild are canvas2d…

  7. giles says:

    You’re quite right, they are — I should have checked more closely. Post updated appropriately. Perhaps he’s calling it WebGL because it’s 3D in the browser, not realising that there’s a specific technical meaning for the term.

  8. “aa” is right – of course & “giles” too ;-) – the demos are canvas2d at the moment – I’ll try to combine WebGL (coming soon, I hope) and 2D canvas – and real WebGL implementations – to find out differences in performance etc. – stay tuned! Sorry for the wrong wording – I’ll correct that on my website!

  9. giles says:

    Thanks, Robert — they’re cool demos even if they’re not WebGL, looking forward to seeing hardware-accelerated versions :-)

Leave a Reply

Subscribe to RSS Feed Follow Learning WebGL on Twitter