修改其值的最快方式：
创建：
Mutable Storage
To create mutable storage for a buffer object, you use this API:
void glBufferData(enum target, sizeiptr size, const void *data, enum usage)
The target parameter is just like the one for glBindBuffer; it says which bound buffer to modify. size represents how many bytes you want to allocate in this buffer object.
The data parameter is a pointer to user memory that will be copied into the buffer object's data store. If this value is NULL, then no copying will occur, and the buffer object's data will be undefined.
The usage parameter can be very confusing.
修改：
We have seen that glBufferData can be used to update the data in a buffer object. However, this also reallocates the buffer object's storage. This is not usually what one wants, as recreating the buffer can often be a heavyweight operation.
Instead, one can use the following API:
void glBufferSubData(enum target, intptr offset, sizeiptr size, const void *data)
The offset parameter is an integer offset into the buffer object where we should begin updating. The size parameter is the number of bytes we should copy out ofdata. For obvious reasons, data cannot be NULL.
Modifiable buffers With Mapping VS glBufferSubData:
Generally speaking, mapping a buffer and writing to it will be equally as efficient as glBufferSubData. And in most cases, it will be much faster, particularly if invalidation and other Buffer Object Streaming techniques are employed.
To cover this, flags should be set to GL_MAP_WRITE_BIT. This lets the implementation know that you will not be using glBufferSubData at all.
glBufferSubData is a nice way to present data to a buffer object. But it can be wasteful in performance, depending on your use patterns.
For example, if you have an algorithm that generates data that you want to store in the buffer object, you must first allocate some temporary memory to store that data in. Then you can use glBufferSubData to transfer it to OpenGL's memory. Similarly, if you want to read data back, glGetBufferSubData is perhaps not what you need, though this is less likely. It would be really nice if you could just get a pointer to the buffer object's storage and write directly to it.
You can. To do this, you must map the buffer. This gives you a pointer to memory that you can write to or read from, theoretically, just like any other. When you unmap the buffer, this invalidates the pointer (don't use it again), and the buffer object will be updated with the changes you made to it.
Mapping a VBO Code:
glBindBuffer(GL_ARRAY_BUFFER,mVBOtrackMidHandle[0]);
float * pMidPathVertex=(float * )glMapBuffer(GL_ARRAY_BUFFER,GL_WRITE_ONLY); for(int i=1;i<10;++i)
{
pMidPathVertex[i*12+7]=pMidPathVertex[(i-1)*12+4];
pMidPathVertex[i*12+10]=pMidPathVertex[(i-1)*12+1];
pMidPathVertex[i*12+4]=pMidPathVertex[i*12+7]-10;
pMidPathVertex[i*12+1]=pMidPathVertex[i*12+10]-10; } glUnmapBuffer(GL_ARRAY_BUFFER);
mapping weak：
Everything has a price. The price of this is that you must deal with the ordering of reads and writes. By mapping the buffer in this fashion, you are taking full responsibility for synchronizing mapped access operations with OpenGL (and with other direct uses of the API).
When you use a mapped pointer to write to a buffer, the data you write does not immediately become visible to OpenGL. It only becomes visible to OpenGL when you issue a glMemoryBarrier(GL_CLIENT_MAPPED_BUFFER_BARRIER_BIT) call.
One thing to remember about buffer mapping is this: the implementation is not obligated in any way to give you an actual pointer to the buffer object's memory. It is perfectly capable of giving you a pointer to some memory that OpenGL allocated just for the purpose of mapping, then it will do the copy on its own time.
If you are attempting to stream data to the buffer, you should always map the buffer only for writing and you should write sequentially. You do not need to write every byte, but you should avoid going backwards or skipping around in the memory.
Problem:Buffer Object Streaming
OpenGL puts in place all the guarantees to make this process work, but making it work fast is the real problem. The biggest danger in streaming, the one that causes the most problems, is implicit synchronization.
The OpenGL specification permits an implementation to delay the execution of drawing commands. This allows you to draw a lot of stuff, and then let OpenGL handle things on its own time. Because of this, it is entirely possible that, well after you call whatever operation that uses the buffer object, you might start trying to upload new data to that buffer. If this happens, the OpenGL specification requires that the thread halt until all drawing commands that could be affected by your update of the buffer object complete.
This implicit synchronization is the primary enemy when streaming vertex data.
There are a number of strategies to solve this problem. Some implementations work better with certain ones than others. Each one has its benefits and drawbacks.
试验：定点数组大小，sizeof(float)*3*4*100*100*300， 共100*100*300个面片 GT755m，此时GPU和CPU处理数据的时间基本相同。
但是 经过试验后 发现如果需要替换全部数据glBufferData与glBufferSubData效率基本相同，可能是因为CPU与GPU本身存在并行的时候 使得glBufferData(Null)所体现的GPU并行数据方面无效。大概80ms左右
glMapBuffer()会非常慢 竟然需要1300ms 是前者的15倍，分析后 发现 glMapBuffer后获得GPU的指针，然后直接对其操作 ，这种行为会导致GPU进行synchronization, 而本身又是使CPU对GPU的直接操作，从而使CPU和GPU的同步，因此效率很低。
而避免synchronization的方法 使用glBufferData(Null)和glMapBufferRange()，使用glBufferData(Null)后则没有效果(是数据大小不够典型？)，而glMapBufferRange()待续。。