I tried implementing this once, and there was no performance difference. al_hold_bitmap_drawing model doesn't really work for primitives anyway, as they, somewhat unlike bitmaps, occasionally take quite a bit of CPU work to generate in the first place... and the fact that the al_hold_bitmap_drawing model requires you to regenerate the vertex data every frame makes the idea somewhat moot. A real solution would involve the ability to "record" a sequence of drawing calls that can be replayed later.

That said, I, personally, am no longer interested in this kind of performance optimizations. Half the time they do nothing on my computer, half the time they help performance only on my computer. al_hold_bitmap_drawing, for example, pretty much did nothing on my old GPU. I'd suggest optimizing on a different level.

Out of pure theoretical interest, care to elaborate?

I guess you ara passing the vertex data that you have pre-calculated to al draw prim right?

Wouldn't this be quite similar to what al_draw_ellipse does? Where exactly ther esi the performance hit?

I think in this case, you just load everything up into a VBO and fire it off with a glDrawArrays or whatever the function is.

Ah yesss, I get it...pretty straightforward indeed

I know this may sound stupid, and I am partially hijacking the thread but I would like to understand a little bit more of the inner workings of the addon, so...for the circles, can't you use the al_calculate_arc with 0 to 360 as theta and delta? you could then append the calculated buffer into your vertex buffer and call al_draw_prim?

Ok, here it is. This patch adds the following functions:

void al_hold_primitive_drawing(bool hold);
bool al_is_primitive_drawing_held(void);

Which function about the same as the bitmap equivalents. The deferred drawing is only implemented for al_draw_filled_triangle and al_draw_filled_ellipse.

It's up to you to come up with a benchmark where this sort of nonsense helps .