* Previously this would be treated as std430 due to being 'tight' array packed,
even though std430 only allows as tight as the base alignment - which for a
float3 is 16-bytes still.
* Unifying these views means that constant buffers have all the same
reformatting and it avoids having multiple paths for what is now effectively
the same control (a buffer can either have fixed data, repeating data, or
both)
* GL and Vulkan allow buffers to have fixed variables before a trailing AoS
unbounded array. These fixed variables can't be easily displayed in a table
and previously we skipped them. Now we display these in a tree format.
* We also support formats which don't have an unbounded array at all and display
these just with the tree. This will allow the BufferViewer to subsume the
capabilities of the ConstantBufferPreviewer (though it needs to handle opaque
non-buffer-backed variables, and slot-following).
* This allows the calling code to pass a hint of what packing is known or likely
to be used, meaning less generated manual offsetting/padding when the implicit
rules cover it.
* Instead of having a global tight/non-tight we now let the format string
specify the packing rules (defaulting to scalar - i.e. tight packing as
before), and use the resulting properties to calculate packing.
* This is primarily for GL/VK where the packing rules are not pre-defined and
are also not explicitly reflected, so we instead see what rules are broken
along the way to get the most conservative ruleset we can (that way minimising
the need for manual offset decorations)
* There are several different API packing rulesets - GL has std140 and std430
(and packed/shared, which is implementation defined but is likely to be
similar to one of these or more conservative), VK effectively has rules for
those both, as well as scalar packing which is close to C packing. D3D has one
ruleset for cbuffer packing similar to std140, and effectively scalar for
structured resources.
* These rulesets are quite similar and only differ by the properties here. There
is one exception in the handling of empty structs - but in GLSL these are
illegal so we will take the HLSL interpretation and always treat them as 0
bytes.
* We still need to handle multiple elements in the root of a struct specially by
commenting out the fixed members, but the final element needs to go through
the normal DeclareStruct() path to handle things like per-column padding in
matrices etc.
* One automodule in a file for our modules is way too much, so we split it into
files. Unfortunately this means that only one file can have those classes and
functions be linkable from elsewhere.
* Instead we bite the bullet and manually curate the items into pages, and at
the same time subdivide the 'enums and data' page more which is a general
readability and usability win as well.
* We also add some previously not-included functions, and add a doc-build time
check to ensure that functions and classes aren't omitted from the
documentation in future
* Actually creating a 64-bit spinbox is not feasible without constructing it
almost from scratch due to how much QAbstractSpinBox depends on private
internals that can't be overridden. Instead use a QDoubleSpinBox with no
decimals since we don't need the full 64-bit range, and the mantissa of a
double is enough.
* This lets the user override the default application font.
* Unfortunately Qt seems to behave inconsistently with font scaling from the
system, so we take the font size initially from QApplication::font() (which
doesn't always pick up the font size) and scale from there. While this might
cause some font scaling to be lost it does mean at least we have a consistent
scale, as otherwise you get some text scaling and others not.
baldurk