WebGL Browser Stress Tests Using Processing.js

I’m working on XB PointStream, a tool which will emulate Arius3D‘s PointStream. XB PointStream will use WebGL to render thousands of points efficiently in the browsers.

I was curious to see how many points Processing.js could churn out using WebGL. If fast enough, it could potentially be used as underlying rendering engine for XB PointStream. So I wrote a Processing sketch which rendered thousands of points, and I took some measurements. I didn’t have any point clouds at hand, so I just generated a few thousand points myself:

Once I recorded how long it took Minefield and Webkit, I started hacking in some optimizations in the Procesing.js library. I knew I could start with reducing the number of calls to uniformMatrix*. For example, in Processing.js, the perspective and view matrices are set every time a point is rendered, which is unnecessary. I moved these function calls out and ran the browsers through the tests again. I was pleased to see rendering time was cut roughly in half.

I then filed a bug on our lighthouse account to reduce the number of uniformMatrix*. We still have a way to go in performance, especially since these tests are static renders, don’t account for download time and don’t use real-time lighting.

No Chromium Tests Yet

It’s unfortunate that I couldn’t benchmark Chromium. I even took extra steps to get the tests to run by placing the Processing sketch within the HTML file so Chromium wouldn’t throw XHR errors. I also merged one of my Processing.js patches which does not transpose matrices in calls to uniformMatrix*, which the nightly has issues with. But even after doing this, Chromium surprisingly rendered extremely slowly. This was the exact opposite of what I expected since it always outperforms the other browsers. I could try to find the nightly which renders properly, but I don’t have time to sift through all those nightlies. If someone knows when WebGL was broken, let me know.