* Tacking -official onto the git hash was a hack only needed on windows,
and since we want more information it doesn't scale.
* Instead we track anything we need to know about the version in
separate variables, like whether it's a stable build or a nightly/
local build. Or if it's built by a downstream distribution then the
version number for the downstream build.
* The suffix is superfluous in the string name - it can be reconstructed
using the array size data. It just confuses things when trying to
replicate a variable declaration. E.g. int indices[4]; shouldn't be
listed as int[4] indices[4];
* Our function to get texture data requests a single mip and a single
array slice at a time. However this interacts badly with the GL get
function that returns array data all at once.
* Worst case, we end up fetching N array slices N times, meaning we do
N^2 work, and allocate way more memory than is required. There was
also a bug that caused the allocated memory for compressed arrays to
return all array slices instead of returning one slice, offsetted.
* Now instead we cache the returned array data and look it up for
subsequent requests, since it's very likely that we're going to ask
for the other array slices.
Using "1" here was very specific to the build system, as noted by the comment.
When run on systems with older APIs install, it resulted in java compile errors.
* If an app only relies on reflection to set up its VAO, then its VAO
will morph to match the built-in implementation defined initial
locations of attribs and fragdata.
* Then when replaying on another implementation the VAO will no longer
match the changed locations.
* So instead we save the locations (whether they're user set or still
implementation defined) and restore them explicitly.
* We need to relink programs to update attrib bindings, which means the
shaders need to be still attached. There doesn't seem to be any harm
in leaving a shader attached to a program that should be detached -
it can still be used just fine in other programs.
* For VS output we can statically determine how much space is needed and
allocate more if we need to.
* For tessellation/geometry shader output, we need to run a query to see
if there was enough output space, then reallocate and run it again.
* On GL there isn't a built-in xfb query, only as an extension with poor
support, so we just resize to allow the maximum expansion.
* I'm not clear on if this is safe or sensible - somehow the source
program can report multiple outputs bound to the same index (e.g. 0)
but that's illegal to set explicitly ourselves. So we just ignore the
subsequent variables and hope the first one we find is the valid one.
* The other alternative is to set the subsequent variables to some bind
higher than all of the rest, or fill in holes (e.g. if we see 0, 0, 1
then bind the second 0 to 2).
* Since we're promoting everything, we reset the behaviour of
RDTreeWidget so that it's not doing anything different by default.
* RDTreeWidget's interface is a bit different, exposing some useful
things like a single selected item and so on.
* We also can't set columns in the Qt Creator UI anymore, so we set them
from code.
* We add our own custom item model to handle the cases we need. We can
also make a few assumptions and optimisations around things we can
safely assume like e.g. nodel columns won't really change after init.
* This lets us have full control over batching updates, which was the
main motivation, but it makes it easier to extend in future (e.g.
adding single per-item tags instead of the heavyweight Qt::UserRole
data elements).
baldurk