* If we save the current capture from a connection window we want to do that via
the main window so the UI can be properly updated and so we can save it
properly through the replay manager, so the old one can be removed safely.
* When using VS In we want to ignore the W component, but that already happens
explicitly for vulkan/GL in the shader. Mirror that same solution to D3D
instead of trying to force a 3-component format which may not be supported
(e.g. on AMD R16G16B16_*)
* This applies when selecting a marker region, the effective EID is the one
actually replayed to an represented in the UI. As-if it were directly
selected.
* In v1.15 if you upgraded from a previous version and had a renderdoc config
file then the persistent storage storing the filters would get loaded with an
empty variant map, so the defaults could be set. However if you had no config
file at all this wouldn't happen so no defaults would be set.
* We detect the case where we load an old profile and it has blank current
filter or saved filters, and fill in the defaults now. If the filter has been
customised or some saved filters exist, respectively, we don't touch them.
* The UI will become non-functional and the backend will be replaced with a do-
nothing one that keeps things alive without needing error bulletproofing
everywhere in the real backend.
* Instead of storing the API pipeline states in the replay driver and returning
pointers, we store them in the replay controller and write into it from the
replay driver.
* This will allow us to remove the replay driver and still keep any previously
obtained references/pointers to the pipeline state valid.
* On GL you can specify a vertex attribute that's stored as int but gets
converted to float with glVertexAttribFormat instead of glVertexAttribIFormat.
However if the shader accepts an int this is invalid and the value is
undefined - we emulate this as the float bits being read as int directly, but
that's not guaranteed behaviour.
* Normally we don't emulate this kind of mis-cast behaviour and just display the
type of data passed to the shader, but in this case GL lets you specify three
types (stored as int, cast to float, read as int) so our normal behaviour of
just showing the input can be more misleading than normal.
* This means we'll jump to the nearest _visible_ result, rather than just the
next result whether or not it's visible. This also applies to EID searches,
when doing a go-to on a particular EID we'll end up jumping to the next
visible EID.
* We split stepping for source debugging into step over/into/out depending on
how it handles function calls. Step Into is the same behaviour as before - it
steps to the next source line executed regardless of if it's inside a function
call. Step Over is similar but will not enter function calls. We define that
as the callstack growing (so staying the same or shrinking - returning from a
function - is OK), and this is as accurate as the underlying debug
information. Step Out will run until the callstack shrinks, i.e. returning
from a function.
* This is a slight behaviour change of keyboard shortcuts - F10 was effectively
doing step into and will now step over. F11 will step into which is the old
behaviour.
* All these variants have backwards versions, and to remain consistent we keep
the shift modifier as forwards/backwards. This differs from visal studio where
step out is shift-F10.
* The seems like the best balance - using any other variant would likely confuse
muscle memory of anyone used to visual studio (where these shortcuts are
intended to mimick), if only because F10 would be step into whether or not F11
is used for step over or some other key which would likely be even more
confusing either way. Trying to twist to use Shift-F10 for step out would be
inconsistent with the other backwards running operations and likely cause more
confusion than it saves in matching VS's shortcuts exactly. Also an accidental
Shift-F10 is not too destructive, the user can realise it didn't Step Out
forwards, and press Ctrl-F10 or look up the button.
* The hope is that most likely people doing source debugging and familiar with
these keys expect F10 to step over, so the previous behaviour was unexpected
but easy to work around, and that changing the meaning of the key won't
disrupt them. Or at least the disruption is less than other alternatives.
* This is a deliberate break of compatibility since the field is now often
empty, for non-markers. This means code will get a more explicit error when
the name is being referenced, so it can be updated to fetch the name it needs
as needed.
* There's not a good accepted terminology for this kind of event, and for
historical reasons 'drawcall' has been the accepted term, even though
that can be quite confusing when a dispatch or a copy is a 'drawcall'.
* This is particularly highlighted by the event browser filters where
$draw() includes draws and dispatches, but $dispatch() only includes
dispatches, it's hard to intuitively understand why $draw() matches all
of these calls.
* As a result we've defined the term 'action' to cover these types of
events in the same way that we defined 'event' in the first place to
mean a single atomic API call.
baldurk