* When a compatibility context is created (via the old CreateContext, or
via an appropriate CreateContextAttribs call), we can still do the vendor
checks but we want to make sure we perform them again if we ever create a
core profile context. Note that actually *using* a compatibility context
isn't supported at the moment, but this won't explicitly break that.
* These values are used to show the current pipeline state (as it's
convenient to show this data with the rest of the 'state', even if it's
not state. That means they need to be set every time when executing, not
just once when reading.
* It seems like there's some buggy behaviour when mixing and matching 'old'
style vertex attrib pointer/offset functions, and the new attrib/vertex
buffer binding style (which we use in VAO initial state since it's a
superset of functionality).
* Fortunately, the spec defines exactly how VertexAttribPointer is defined
in terms of the new system, so just do the replacement ourselves.
* e.g. if the 'wrong' VAO was bound at the time we replayed a
bind-to-create chunk, then we'd trample that VAO state (and it might not
ever be restored). So when reading, not executing, save and restore the
buffer binding.
* We need to have more comprehensive frame references for several reasons
but this will handle the case where a buffer is created, bound, deleted
before the frame ends.
* This lets us detect if the FBO/VAO behaviour is different from the main
spec, and so we won't miss deletes or other events if the context is
different since we'll treat them as shared like any other object.
* This means you don't hit a debugbreak and fire an exception in profile if
you load an image file (which tries to load as a logfile first, and
fails).
* Important buffer chunks like the first glBindBuffer and glBufferStorage
could happen in the frame, so need to preserve order between those and
glTexBuffer.
* It is only replayed in READING, so once at startup - not once per frame
replay.
* None of these require extra serialisation functions, but some upgraded
to DSA style serialise instead of selector serialise functions.
* There's a lot of duplication here now (expecially for MultiTex calls).
This could really do with cleanup soon.
* In OpenGL and D3D11, resource handles (pointers or namespace/uint pairs
respectively) could be reused, so we can't use these to denote resources
that are getting updated regularly and should have updates ignored.
* I don't know how I got away with this for so long, or why I used pointers
in the first place. It could have predated resource IDs maybe.
* Until I have a proper UI this is convenient when capturing, especially if
you point the folder at a samba share on windows so you can load the
capture up directly.
baldurk