State management in D3D

[H. Verbeet]

On 11/09/06, Ivan Gyurdiev <ivg231 at gmail.com> wrote:
> I guess that seems like a large undertaking, and those are all doomed to
> failure.. but it doesn't have to be.
>
> The key idea that I care about seems to be to move GL code from device.c
> into the data structure object, and figure out a way to apply a set of
> delayed states at draw time. We don't have to replace everything right
> now - we could have 2 coexisting data structures and slowly move things
> from one to the other, but I wanted to see if people agree with that idea.
Ok, so the main idea is to separate the applying of GL state from the
tracking of D3D state. Looks like a good idea. What I would like to
add to that is something BBrox mentioned on IRC a while back...
grouping related states together and marking that group dirty / clean.
That way we would get a tree like structure for the states, which
would make checking what states changed and need to be applied
somewhat faster. While it would be possible to add that afterwards, I
think it would be easier to just take it into account when designing
the new stateblock structure.

> I don't like the way things are done right now - Set* functions can do
> one of two things - record to a stateblock, or apply state. Then the
> stateblock calls the Set* functions itself when it's applied - seems
> very ugly to me [ and also in certain places we're forced to disable
> recording to get a state applied immediately using a Set* function ].
You always record to a stateblock, be it the main device stateblock or
the update stateblock, but yes, it's pretty ugly.