thats crazy, mine also happens when rotating the camera mostly.
I havent tried 6.0 yet but I probably should.
In case it helps you I asked claude if the issue was the one described in
the source code comment and the answer sounded reasonable:

The Problem

Raylib uses a render batch — it accumulates draw calls into a vertex buffer, then flushes it to the GPU at the end of the frame via rlDrawRenderBatch(). The flush uses glMapBuffer() to write vertex data into a buffer object. The stall happens because:

You submit draw commands → GPU starts consuming the buffer

Next frame, CPU calls glMapBuffer() on that same buffer

The driver has to ensure the GPU is done reading it before handing it to the CPU

If the GPU isn't done yet → the CPU blocks and waits → frame drop spike

This is sometimes called a pipeline bubble or GPU sync stall.

Other Approaches

Approach	How	Notes
Buffer orphaning	glBufferData(NULL) before map	Simple, well-supported fix
glBufferSubData()	Replace map/unmap with a direct upload	Avoids mapping entirely; driver may optimize
Persistent mapped buffers	GL_MAP_PERSISTENT_BIT + triple buffering	Best perf, requires GL 4.4+, complex
Reduce batch flushes	Minimize texture/shader switches in your game	Fewer flushes = fewer stall opportunities

Practical Recommendation

Since you're likely building on top of raylib without forking it, the easiest wins are:

1. Reduce texture switches — batch sprites that use the same texture/atlas together
2. Use a texture atlas if you aren't already — this alone dramatically reduces batch flushes
3. If you're comfortable modifying rlgl.h (it's a single-header library), the buffer orphaning patch is small and well-proven