* 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.
* 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.
* 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.
* The filter icon was confusing since it had a 'refresh' badge instead of
'save/load/recent' type badge, and making the latter readable in a few pixels
is not feasible. Having the combo dropdown with saved filters is as intuitive
and works in-line.
* The current filter is preserved across runs even if it's not explicitly saved.
Saved filters are only updated with an explicit save - loading a filter then
making a change just cahnges the current scratch filter, it doesn't update the
saved filter until the user explicitly saves it.
* This is a little bit inconsistent because they are technically draws, but
they're only draws so they can include the trailing API events in a region.
* Think of it this way:
Imagine we instead made PopMarker just a normal API event (which is how we want to treat it) and instead inserted a second 'internal' draw at the end of each region to contain the popmarker. This internal draw would be hardcoded to never show up in filters no matter what - even with an empty include-all filter. But it contains the other API events so they can be selected individually and filtered in/out.
In this scenario it's functionally equivalent to just using the PopMarker as that 'internal' draw containing its own API event and making it fail all draw filters. The only difference is that users can manually filter in the PopMarker draw with flags if they want.
Sebastien Alaiwan