* For now, just redirect to 127.0.0.1 and assume the user has proper
port forwarding set up, but in future we'd do this ourselves and maybe
parse out a device name after the adb:
* It seems many viewers don't look at the order specified, and just
assume that the channels are in ABGR order. Changing it won't affect
any loaders that do respect that order.
* When transferring over the network, we keep texture data consistently
in GL origin-bottom-left order. This means we can just flip images on
display and otherwise have things consistently behaving, while still
preserving the behaviour of flipping on saving to disk to try and
mostly 'do the right thing' when saving an image.
* The behaviour should be the same as before except for remote proxying
which is fixed. The behaviour for GL is still that compressed images
saved as compressed will appear to flip vertically from what is
natively displayed in the UI, but I think this is the only sensible
way to behave (and anyway, flipping compressed images is far too
involved to be worthwhile).
* Also allow disabling GL a little better by removing the dependency in
renderdoccmd.
* Disabling them now completely removes all xcb and xlib build
dependencies. The resulting library/executable is only useful in
limited situations - e.g. replaying vulkan remotely which doesn't need
any window system interaction. Or capturing vulkan as well with the
KHR_display WSI extension which doesn't need any built-time includes
or libs.
* If the machine idents differ in significant ways that we'd consider
it to be a different platform (currently just OS), and if so mark it
as supported but suggested to be replayed remotely.
* This is primarily for vulkan, which supports either xlib or xcb (and
not necessarily both). GL still only supports xlib, windows and
android only support one system regardless of API.
* This should also support xlib again for fetching keystates etc.
* In-application API is bumped to 1.1.0 as a new function pointer is
added to the end of the structure.
* This comes with some caveats - capturing a frame is fairly heavy
weight, so capturing a frame might throw off timing-related bugs you
are trying to capture in subsequent frames. If you know your bug is
every other frame though, capturing two can be a quick way to ensure
you get it.
* This is only applicable really on D3D11 where the underlying texture
can be typeless, and a default interpretation as unorm/float won't
necessarily how the texture is actually being used.
* The UI would prevent you from selecting too high an instance for a
draw, but if you selected a non-zero index and then selected a non-
instanced draw, it would try and fail to render instance N.
* 99% of the time, you'll only have localhost and the application will
be running on the first ident checked which will return a valid socket
almost immediately.
* Instead of continuing to search through each valid port before
returning valid data, we change the enumerate function to just find
the next valid port and return - so we can update the UI as soon as
we have the first result.
Michael Rennie