Is there something wrong with creating separate buffers for positions and texture coordinates? This could help, https://www.opengl.org/wiki/Vertex_Specification_Best_Practices#Vertex.2C_normals.2C_texcoords

Maybe something like this:

// bind, update and set the pointer for positions
glBindBuffer(GL_ARRAY_BUFFER, position_buffer);
glBufferSubData(...);
glVertexPointer(...)

// bind, update and set the pointer for texture coordinates
glBindBuffer(GL_ARRAY_BUFFER, texcoord_buffer);
glBufferSubData(...);
glTexCoordPointer(...);

// bind index buffer
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, index_buffer);

// Draw
glDrawElements(...);

For this kind of thing you're really better off using a vertex shader to manipulate your positions. The function that changes positions can be coded in GLSL (perhaps with a uniform or two to control it), with all of the vertex data remaining static.

Otherwise you can achieve a similar effect by loading a new modelview matrix that represents your stretching.

Whichever way you choose, you need to be aware that VBOs are not intended for this kind of partial update. You can certainly do it, but the best use of VBOs comes from either having completely static data in them, from replacing the entire set of data, or from appending to existing data up to the maximum size of the buffer object. But trying to brute-force their usage in the same way as if you were still using immediate mode is extremely unlikely to end well.

I think it should be fine to update the data directly, especially when you're rendering just 2D stuff. You can optimize it later if it really becomes a problem with the performance.

But yeah, when you have a lot of vertices per object, you should transform those with matrices instead. This way you don't have to modify the actual vertices at all.

But trying to brute-force their usage in the same way as if you were still using immediate mode is extremely unlikely to end well.

I feel like GLSL is a little too much for me at this point. Would you say that it's better to replace both the vertex data and the texture coordinates rather than partially update in this case when it comes to performance?

No, I'd say it's better to profile and see which approach is fastest in your own program.

As a general guideline however, (1) interleaved data is going to be faster than non-interleaved data, and (2) updating all of a contiguous region in a VBO is going to be faster than jumping around to update smaller non-contiguous regions. Using non-interleaved data can help you avoid (2) (as you've discovered) but then you get bitten by (1).

To be honest, there are still some situations where not even using VBOs at all may be the best approach, and it looks as though you've got one here. If you've just got a single quad in that VBO, and if you need to update the data dynamically each frame, then glBegin/glEnd may even be faster. Remember - Quake used glBegin/glEnd and didn't suffer too much from it, so while it may not be the most optimal, it's still not as slow as some people might lead you to believe.

Quake used glBegin/glEnd and didn't suffer too much from it, so while it may not be the most optimal, it's still not as slow as some people might lead you to believe.

You should rephrase it as "Quake used glBegin/glEnd with 90s GPU hardware if they had GPU hardware at all". :D

Quake used glBegin/glEnd and didn't suffer too much from it, so while it may not be the most optimal, it's still not as slow as some people might lead you to believe.

You should rephrase it as "Quake used glBegin/glEnd with 90s GPU hardware if they had GPU hardware at all".

And it still runs nowadays.

The point is not to be a glBegin/glEnd lover, the point is to pick the appropriate solution for the problem you're trying to solve. Using buffer objects the wrong way will be slower.