WebGL and OpenGL Performance

Question

Over the past month I have been messing around with WebGL and found that if I create and draw a large vertex buffer, this causes a low FPS. Does anyone know if this will be the same if I used OpenGL with C ++?

Is this a bottleneck with the language used (JavaScript in case of WebGL) or GPU?

WebGL examples like this show that you can draw 150,000 cubes using a single buffer with good performance, but something more than that, I get FPS drops. Will it be the same with OpenGL, or will it be able to handle a larger buffer?

Basically, I have to decide to continue using WebGL and try to optimize the code or - if you tell me that OpenGL will work better, and this is a bottleneck at the speed of the language, switch to C ++ and use OpenGL.

Answer 1

If you have only one drawArrays call, there should not be much difference between OpenGL and WebGL for the call itself. However, setting up data in Javascript can be a lot slower, so it really depends on your problem. If the bulk of your data is static (terrain, rooms), WebGL may work well for you. Otherwise, setting up data in JS may be too slow for your purpose. It really depends on your problem.

ps If you include more detailed information about what you are trying to do, you are likely to get more detailed / specific answers.

Answer 2

Joke, I wrote a tile-based game in early 2000 using the old glVertex() style API, which worked perfectly smoothly. I recently started porting it to WebGL and glDrawArrays() , and now on my modern PC, which is at least 10 times faster, it gets terrible performance.

It seems that the reason is because I came up with a call to go glBegin(GL_QUADS); glVertex()*4; glEnd(); glBegin(GL_QUADS); glVertex()*4; glEnd(); using glDrawArrays() . Using glDrawArrays() to draw a single polygon in WebGL is much slower than using glVertex() in C ++.

I do not know why this is so. Maybe this is because javascript is a slow dog. Perhaps this is due to some context switching issues in javascript. Anyway, I can only make 500 calls with one glDrawArray() polygon, still getting 60 FPS.

Everything seems to work around, doing as much as possible on the GPU and making as few glDrawArray() calls as possible. Can you do this, it depends on what you are trying to do. In the example with the cubes you linked, they can do everything on the GPU, including moving cubes, so it’s fast. In fact, they cheated - usually WebGL applications will not be like that.

Google had a conversation where they explained this technique (they also unrealistically calculate the movement of an object on the GPU): https://www.youtube.com/watch?v=rfQ8rKGTVlg

Answer 3

OpenGL is more flexible and optimized due to the use of new versions of api. It's true if you say that OpenGL is faster and more efficient, but it also depends on your needs.

If you need one cubic grid with texture, webGL will be enough. However, if you intend to build large-scale projects with a large number of vertices, post-processing effects and various rendering methods (and the type of displacement, parallax display, vertex or, possibly, tessellation), then OpenGL may be the best and reasonable choice.

Optimizing buffers for a single call, optimizing them can be done, but it has its limits, of course, and yes, OpenGL will most likely work better anyway.

To answer, this is not a bottleneck in the language, but the api version used. WebGL is based on OpenGL ES, which has some advantages, but also works a little slower, and it has more abstraction levels for processing code than pure OpenGL, and this is the reason for performance degradation - more code is required.

If your project does not require a web solution and does not care about which devices are supported, then OpenGL will be the best and smart choice.

Hope this helps.

Answer 4

WebGL is much slower on the same hardware than similar OpenGLs, due to the high latency on every WebGL call.

On the desktop OpenGL, this overhead is at least limited, although still relatively expensive.

But in browsers like Chrome, WebGL requires that we not only cross the FFI barrier to access those OpenGL API calls (which still carry the same overhead), but we also have security check costs to prevent GPU capture for computing.,

If you look at something like glDraw* that is being called per frame, this means that we are talking about perhaps ( glDraw* ) order (s) of fewer calls. There are more and more reasons to choose something like instancing , where the number of calls is drastically reduced.

Answer 5

The main thing you can do to improve WebGL performance is to properly optimize your assets. See this engine manual for example.