Hacker News Reader

Comment by izacus | Hacker News Reader

Hmm, this actually runs surprisingly slow (I have a top of the line 15" MBP with discrete graphics and it's not hitting 30fps). What's the deal with that? Is WebGL just so inherently slower than "proper" OpenGL powering games? Lack of optimization? What are the bottlenecks?

View on HN

WebGL is great for most use cases, and generally pretty comparable to OpenGL in terms of performance.

This vis is rendering ~11 million vertices which is quite a bit for any GPU to render. There are some optimizations that could be made — chunking, frustum culling, LOD, depth testing, etc — but probably not trivially. It would change the look & feel of the demo (things "popping" in and out or lack of overlapping buildings, etc) and probably take a significant effort to code.

You can see Taylor's code here, though: https://twitter.com/taylorbaldwin

For static geometry like this, the entire scene should be uploaded to the GPU in a few calls when you open the page, and then never again. Only the transformation matrix, a 4x4 matrix which transforms vectors from world space to display space, needs updating. There's no reason this shouldn't run at 60fps on any machine that supports WebGL (excluding CPU-only implementations).

The geometry in this demo already is static.

The app is vertex bound since the geometry has 11 million vertices, which is not trivial for any GPU to render.

I set a breakpoint at drawArrays to verify this, and it's indeed rendering 10,965,264 vertices. It's using neither indexing nor triangle strips, so it uses no post transform cache, and the vertex count is needlessly inflated by at least 3x. But that's still a lot higher than I thought it'd be.

How does that number compare to for example Cities: Skylines which renders cityscapes smoothly on the same hardware?

I don't know Cities: Skylines but I imagine each city rendering engine has its own set of challenges and performance considerations.

Generally my point is: graphics programming isn't always trivial, and it takes time/practice to debug and optimize a WebGL scene with millions of vertices. Comparing this WebGL side project to a full-blown city-scape game engine is apples and oranges.

I'm guessing the largest cause of the performance not being great is the large amount of data, and the approach to render it is not optimal. If the same rendering algorithm was implemented using OpenGL instead, I suspect the performance would not be significantly different from this WebGL version.

If you want a random example of a well-optimized demo that uses WebGL for rendering, try the demo at https://www.funkykarts.rocks/demo.html and see how well that performs.

You can compare this with Google Maps, since IIRC Google Maps also uses WebGL, and renders all of Manhattan with far more detail and without a snag.

Reply on news.ycombinator.com