* Most of the main entry points that can fail with relevant reasons now has a
way of specifying a message to return with it. This message can be displayed
to the user to give more information or context about an error.
* The 'no to all' option should always be present if there are multiple unsaved
captures across the connections, even if the current connection only has one
capture and so otherwise wouldn't have a 'no to all' option.
* The 'no to all' option will always discard all unsaved captures in all
connections when closing the window, if the user clicks no on the confirmation
of this, abort the close operation entirely and let them decide how to handle
it (e.g. discarding/saving captures in connections individually).
* This means if you're closing multiple connections and click 'no to all' when
prompting save of instead of discarding just the captures in that connection
then going on to prompt for the next, it discards all remaining captures.
- Add a new combo box and button to camera settings for mesh viewer
- Add a new dialog window for custom axis mappings
- Implement the axis mappings in gl driver (other drivers to come)
* 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.
* 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.
* 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.
* This option (in spite of large warnings) continues to be a pitfall for new and
experienced users alike, trying to use process injection without good reason
and getting into trouble when it breaks.
* This prevents unnecessary conversions back and forth between rdcstr and const
char * when going through interfaces. In the OS specific layer this is rarely
an issue because most of the implementations don't convert to rdcstr, but it
is convenient to be able to pass in an rdcstr directly. The few cases where
there's an unecessary construction of an rdcstr is acceptable.
* A couple of places in the public API need to return a string from a global
function, so can't return an rdcstr due to C ABI, so they still return a const
char *.
* Similarly const char * is kept for logging, to avoid a dependency on rdcstr
and because that's one place where unnecessary conversions/constructions may
be impactful.
* 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
* This is a string type which heavily optimises for immutability and minimal
storage. It only contains one pointer to the string data and always
reallocates on modify. For compile-time literals it doesn't modify or
allocate.
* On x64 we use the top bit in a tagged pointer to store a flag of whether it's
heap or literal, on other platforms it uses a separate field (meaning another
pointer sized value effectively, including padding).
* This is best for structured data which tends to use a lot of immutable strings
for type/name information, and only a few for actual string data (which are
only allocated once and aren't modified after that). Similarly we rarely want
to know only the size of any of these strings, we want the whole string so not
explicitly storing the size is not a big deal.
* Overall this reduces SDObject from 128 bytes to 80 bytes.
* For certain very large arrays it can be nice to defer generation of structured
data until it's needed, since often maybe only a handful of elements may be
needed (or commonly none at all).
baldurk