I find the primitive drawing functions to be very slow compared to the low level drawing routines, al_draw_prim and so on.

It's a shame because some of those functions are quite useful; I don't want to write my own ellipse drawing code for example.

If I can emulate these functions 10x faster using al_draw_prim and buffering, shouldn't there be a way to do that internally? I'm thinking of something along the lines of al_hold_bitmap_drawing.

Any thoughts?

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.

So it seems the functions that are hardest to implement are the least likely to benefit from the optimisation, without adding the ability to record.

I'm a little surprised that the approach was not a win for more simple shapes. On my system, which is a fairly typical PC, I can absolutely go 10x faster using al-draw_prim for lines and polygons.

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?

The difference is that I only call al_draw_prim once, after buffering possibly hundreds of primitives. The primitive drawing functions will kick off a batch every time.

For example, I draw a polygon over every tile in my game for fog-of-war. Without buffering, this would destroy my frame rate.

I also render circles for debug purposes, but they are not so straightforward to optimise.

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.

I still have the primitive holding code somewhere... if you want, I can update it to work with 5.1 and you could see if it does anything.

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?

Hadn't noticed al_calculate_arc. The ability to set the number of vertices is a bonus.

@SiegeLord: Can't hurt to try it, it the code exists. I can compare with my own simple version.

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 .