You should be able to do that effect with 1 draw call. How does your current solution work such that you need >100 draws?

12 hours ago, Sollum said:

Is there any spreadsheet or information on what is considered "normal" amount of draw calls for a mobile/desktop game?

IMHO: For a mobile game, 100 to 200, for a desktop game 1k to 10k.

As Hodgman implies, typically a "ribbon particle trail" is just a single very long strip of quads (or triangles), you can store them all in a single vertex buffer, and draw them in once call.

This is generally a very cheap effect. For fixed length trails, you can even treat the vertex buffer as a circular buffer, and just keep overwriting the oldest quad in the buffer with the new quad as the tracked object moves.

15 hours ago, Sollum said:

GL Immediate Mode

OpenGL's immediate mode has been deprecated for a very long time. Switch to using vertex buffers and glDrawArrays/glDrawElements, and your current performance problems will melt away...

With old immediate mode stuff, you should just be able to use a single glBegin/glEnd pair and all of the glVertex calls in between them.

Streaming data via a VBO is not that bad -- you can send a few hundred megabytes per frame over the PCIe bus without a problem! Sending a few megabytes of vertex is well below the theoretical maximums. In my game I stream 3.5MB of vertex data per frame to draw these vehicle trails and it hardly shows up at all on my performance profiler: http://www.22series.com/assets/images/screenshots/22_racing_series_video_game_future_physics_racer_03.jpg

In D3D this is pretty simple -- you just use the DISCARD flag to tell the driver to orphan the old buffer storage and allocate a new page from an internal ring -- but in GL it's a little trickier to tell the driver that this is your intention. Check out both of these for some different methods of streaming VBO data in GL:

https://www.seas.upenn.edu/~pcozzi/OpenGLInsights/OpenGLInsights-AsynchronousBufferTransfers.pdf

https://www.khronos.org/opengl/wiki/Buffer_Object_Streaming

Orphaning is the easy way to do it (as long as you follow one of the orphaning recipies in the above links), or if you really want to improve performance further (probably only required if you want to push it over 100MB per frame), you can use persistent mapping, and/or unsynchronized mapping (A.K.A. NO_OVERWRITE in D3D) to implement a circular/ring buffer, as mentioned above.

2 hours ago, Sollum said:

I will look into "orphaning", but i am afraid that mobile platforms are not that "powerful" for that

At the same time you'll likely not have as many quads to push as the screen sizes are smaller also.  Also, until performance data tells you it's an issue, don't assume it will be.

2 hours ago, Sollum said:

but i am afraid that mobile platforms are not that "powerful" for that

You might be surprised. Back when I worked on the Fire Phone, there were all sorts of chipset vendor-specific OpenGL extensions to speed up specific performance cases. The high-end mobile chipsets spend a lot of effort on rendering. But at the same time, there be dragons...

Specifically for mobile rendering, I'd recommend the documentation at https://developer.qualcomm.com/software/adreno-gpu-sdk/tools as a starting point (assuming Android/Snapdragon mobile chipset).