Add a column that shows the parent marker for the event range (by default the end event ID)
Add an option to prevent combining resource usage across markers (group by marker)
The tooltip for a resource usage entry contains the full marker path
* The compiler could compile an entry point "foo" into an export "bar". We use
the exported name in most places as that's guaranteed to be unique by the API
and used for cross-referencing, but when recompiling we pass the original
source name as in the debug info.
Qt on Ubuntu 23.04 includes https://github.com/qt/qtbase/commit/f9e4402ffe, which during show() under certain scenarios (for example Qt::ToolTip windows) would destroy and recreate the xcb window.
Adding Qt:WindowStaysOnTopHint to the window flags for ToolTip windows prevents the xcb window from being destroyed and recreated during show().
* This distinction unfortunately does not exist in SPIR-V so we have to carry
around this metadata ourselves. Rather than allowing free specification of
tools based on API, instead pretend that Vulkan and GL SPIR-V are separate
format, and duplicate all SPIR-V tools to handle "both" types. This allows
appropriate tool selection based on the encoding.
* This helps those who have chosen the dark theme where rich resource text uses
the default window text colour assuming it's a contrasting colour against the
background (except when highlighted).
* We store the compiler used (when known) in shader debug info and use that to
select the compiler for editing as even higher priority than the default for a
given language/encoding combination.
* We also ensure that for known tools we add the input and output parameters
last, after any custom parameters, so that they are always present regardless
of what the user puts in.
* 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.
* Most remote replay links are slow enough that the lag introduced by
synchronously fetching and displaying these thumbnails would be annoying for
simple mouse-over scenarios.
* If there would be no tooltip otherwise, it just shows the thumbnail. Otherwise
any tooltip text (like view parameters or image layout) is displayed below the
thumbnail
* If we default to D3D11 at construction time, if we have persist data (very
likely) and it's for another API then we'll have to destroy the D3D11 viewer
and recreate the other API's viewer.
* We instead always have 3rdparty/ in the relevant include search paths and rely
on that. Each library still has its own unique base dir within 3rdparty to
clarify where the include is coming from.
Jake Turner