Why is WebGL rendering speed so inconsistent?

In my application, I draw about 8 million vertices with one call in drawarrays WebGL using the LINE_STRIP flag. I really do not want one long line, I need about 200 thousand short lines, so I close all short lines with additional vertices and tell the vertex shader to β€œclick” strokes on negative z to create invisible bridges. The implementation is quasistatic (the user can click various things that cause re-rendering), so it should not be super-fast, but I really hoped that it would take less than 200 ms on modern computers.

On my laptop [UPDATE: Win7 is running, using multiple Intel i7 processors as its processor and integrated HD Graphics 4000 for the GPU). I get about 100 ms in Chrome, which is good. Oddly enough, Firefox takes about 1-2 seconds. On my Samsung Chromebook 550, I get anything from 600 ms to 2 s, it often starts up quickly, and then subsequent renderings become slower, but it can speed up.

Questions:

  • What can cause a change in rendering speed on my Chromebook?
  • Why is Firefox so slower than Chrome on my laptop?
  • Is it worth it to spend age trying to make it work faster (i.e. can a big improvement be expected)? Any tips?

Notes:

  • For repeated Chromebook rendering tests, the only thing that happens between the renders is the uniform change to switch between color palettes (implemented as textures). Chrome dev utilities do not seem to think that significant changes are occurring in page memory usage during testing.

  • I use gl.finish and console.time to see how long the rendering takes.

  • With the exception of debugging, I draw the orphaned canvas, and then copy the sections of the result to various small canvases on the UPDATE page: using drawImage (with webgl canvas as the first argument). This probably takes a little time, but the numbers reported above do not seem to change much with or without a copy operation and with or without a webgl canvas attached to the body of the page (and visible).

  • UPDATE: there is a limit on the number of vertices that my laptop will do at one time, but the limit seems to fluctuate from moment to moment, if you go over the limit, then it does nothing. Their number is about 8 million, but sometimes it pleases more than 11 million. I have now set it for a batch of 2 million at a time. Interestingly, this seems to make my Chromebook faster, but I can't be sure that it is so inconsistent.

  • UPDATE: I disabled DEPTH_TEST and BLEND as I don't need them. I’m not sure if it mattered.

  • UPDATE: I tried to render using POINTS instead of LINES. On my Chromebook, apparently it occupied about 1 with a size of 0 dots (i.e. didn’t display anything), and then about 1.5-2 s when I increased the size of the dot to 1.2 and 5.

  • UPDATE: Saving everything on the z = 0 plane does not seem to change the speed very much, it may go a little slower (which I expect, since there are a lot more pixels to go through the fragment shader, although the fragment shader just moves the variable directly to gl_FragColor).

+4
source share
1 answer

Although the usual (good) advice is to display as much as possible in each callback, some (at least one of which I know) GPUs have internal buffers used in processing vertex data. Exceeding the throughput of these buffers can lead to performance degradation. Reduce the size of the vertex lots until you see a drop in performance with too small lots.

0
source

Source: https://habr.com/ru/post/1481669/


All Articles