d1manson
commented
10 years ago Or...
- C - buffer with 2n elements, giving info for each wave twice.
- V - buffer with 2n elements giving voltage at time t and t+1 for each wave
Have a uniform which sets the x offset, loop through this and through the corresponding versions of V. We render simple lines, not line strips. This does require double the gpu memory and double the upload, but it has no texture lookup and is a lot simpler.
Actually, the V buffer is the same size as previously (or rather a bit smaller), because here it only has one byte per element not two, and there are only 98 elements per wave not 52.
It may be possible to introduce a dummy extra buffer with a single element that is instanced. Then V can have its divisor set to 1 and C set to 2. The advantage of this is that we half the amount of C data that needs to be sent to the GPU each time the cut is changed, it's also not so different to the original proposal, so could potentially be done as an extra thing rather than having the code rely on it.
For the method at the top of this page, might be able to use a similar trick, setting T's divisor to 1 and C's to 50 and V's to 1. But that only makes sense if T will be automatically repeated.
Really fast rendering of waveforms is a seriously important part of the application. If we can cut rendering time, the UI can include code that renders more frequently, making it a richer, more interactive experience.
One idea is to make use of instanced drawing (currently hidden behind a flag in chrome and temporarily disabled entierly on windows - chromium issue 288391).
In the end this may actually not help that much, and could be even more complicated than the existing algorithm.
The divisor=1 means that the value is fixed while an "instance" of the divisor =0 buffer is rendered, then it increments for the next instance of the buffer.
However, unfortunately, even if it was relatively simple to get the texture coordinates for reading from V (which probably requires additional elements in T and C and is a pain to coerce into a square shaped texture), it is unlikely that a large enough texture can be used [100k waves on a single channel is 5MB, but 1024_1024_4 is only 4MB].Maybe it would be worth looping through multiple textures?