Re: Another small optimization: aglMacro

[Dair G. <da...@re...>]

James W. Walker wrote:

>On the OpenGL list, it has been mentioned that one can get a small=20
>performance boost by using the macro interfaces to OpenGL.

I've always shied away from using this technique personally, as it
really is pretty ugly... :-)


>However some Quesa internal functions would need an extra=20
>parameter.

Plus we'd need extra local variables, if I understand the setup
correctly, i.e., we'd have to have a local agl_ctx in each routine that
made a GL call which was initialised to the context in the instance
data?


>I expect that in most cases the gain would be small, maybe 1%.=20
>However the "multibox" test went up from 4.7 FPS to 5.0 FPS with this
>change.  This would not affect platforms other than Mac.  Any
>comments, or objections to my checking it in?

A 6% change isn't normally something to ignore, but I'd be curious to
see if you get any impact in other tests?

The multibox test I'd expect to spend most of its time updating the view
stack: i.e., showing the cost of per-object processing within Quesa
rather than rendering time (and a lot of that is probably the bogus view
state stack updates on pop).

Normally this only really helps for immediate mode drawing, where you're
doing N-thousand glVertex calls or whatever: as Frank says that's the
case for the transparent path, but shouldn't happen normally.

So I'm kind of surprised you did get anything out of it actually. :-)=20


-dair (I wonder if the place we're saving the time is in IRUpdate.c: we
probably make more GL state calls in there than we do GL drawing calls,
and I bet most of them are happening because of the excessive view state
stack updates)
___________________________________________________
mailto:dair+refnum.com       http://www.refnum.com/