Posted by Wade Walker on Jan 09, 2011; 5:33pm
URL: https://forum.jogamp.org/Multithreading-tp2221001p2222175.html

I'd suggest implementing your program first without any optimizations or multithreading at all. You could get lucky, it might already be fast enough

Then, once you've proved it's too slow, you can do profiling and testing to find the slow parts. It's very hard to guess which GL operations will be expensive unless you gather real performance data.

The operations glGenBuffers, glBindBuffer, glBufferData (with a null data pointer), and glBindBuffer seem like they're only creating a few small objects inside the graphics driver -- they shouldn't be copying any large amount of data.

However, you can't know for sure how the driver is implemented -- it could be doing something horrible, like locking some internal resource and waiting on it.

I always end up regretting when I try to optimize first, before measuring the problem with real data. Usually I waste a lot of effort, and then I have to redo the optimization once I measure the performance for real