Keith Whitwell wrote:
>
> Brian,
>
> I've been thinking about this a little bit & it seems to me there will always
> be good reason to keep both of these state update mechanisms around.
> Additionally, by extending the use of the _NEW_ flags we can overcome a couple
> of uglinesses in the current code base.
>
> We've talked about this before and I'd said that my position was roughly:
>
> - Callbacks (to be replaced/augmented by API hookouts) are the mechanism for
> keeping the hardware driver uptodate
> - _NEW_ flags are used
> - to wake up things like the software rasterizer or t&l mechanism after
> being put to sleep
> - a large amount of state may have changed without any other notification
> - to keep those components uptodate during normal operation
> - this is the current gl_update_state mechanism, split up between core,
> rasterizer and t&l
>
> The two uses for the _NEW_ flags can be handled by the same code -- the only
> difference is the amount of state that might have changed.
>
> To this I'd like note another use for the _NEW_ flags: to notify the driver
> itself after a very large state-change, when using callbacks would be
> cumbersome. The obvious example of such a state-change is in glPopAttrib().
Good point.
I agree that having both _NEW* flags and callbacks is good. It allows
the driver implementor some flexibility.
> Rather than attempting to call callbacks for every piece of state in an
> attribute, consider adding:
>
> ctx->Driver.NotifyStateChange( GLcontext *ctx, GLuint newstate )
>
> or, for consistency:
>
> ctx->Driver.Wakeup( GLcontext *ctx, GLuint newstate )
How are these functions different from ctx->Driver.UpdateState()?
Also, how is the newstate parameter different from ctx->NewState?
> which can be called in these cases. The driver would be expected to know
> enough about it's internal state to handle this event.
-Brian
|
