* This simplifies the code flow because we can be sure that we always have
cached read-only/read-write resources (this was true before, but now it's
clear).
* Using the auto-resizing mode of RDHeaderView resizes based on the whole column
every time, which is wasteful when only a few lines are added to a large log.
* We also reverse Python_ADDITIONAL_VERSIONS so it finds the newest one. It
doesn't seem like there's a way in general to make these match, so we hope
that searching from newest to oldest will find the same in both - or at least
it makes it easier for the user to fix by installing the newest in both.
* It seems like packaging of these two is inconsistent, and pyside2 dev files
being available doesn't always imply shiboken2 dev files are present. Be safe
and check both.
* GL needs special handling because cubemaps need to be treated partially as
arrays to select the target, then not as arrays when the data is retrieved.
* On vulkan command pools aren't necessarily reset often or at all, individual
command buffers are. So the chunk allocator needs to support freeing subsets
of pages. When a command buffer ends we force that page to finish up and store
a list of the pages the command buffer used, which can then be reset back when
the command buffer is reset.
* When the pyside2 we ship was built it accidentally included a small dependency
on Qt5Qml, which we don't distribute so the pyside2 libraries wouldn't load.
* We can generate a tiny stub with the right exports and load it manually from
the PySide2 folder on 32-bit qrenderdoc builds to allow pyside2 to load
subsequently. The stub source is tiny, and added alongside.
* Putting it in the PySide2 folder means that even if someone puts RenderDoc's
build folder in their PATH, our stub Qt5Qml won't break anything because it
won't be loaded. If they put PySide2 in the PATH it might, but then it's their
fault!
* Newer Qt versions will base64 the byte arrays even if we've already base64'd
them so they're safe. To prevent this we explicitly convert to QString
afterwards.
* The entry point is remapped several times:
- ELF header declares it at RVA 0x1234
- [new in this change] The section containing that says it's at addresses
0x1200 - 0x1500, but on disk it's actually at file offset 0x1100 meaning our
entry point is actually 0x100 earlier, at 0x1134
- The ASLR maps the executable section at *file offset* 0x1100 to 0xDEADBEEF00
Importantly when file offset != base RVA, this needs to be taken into
account.
- Finally the entry point is at 0x34 offset into the section because it's
mmapped, so the entry point is 0xDEADBEEF34.
* The timestamp base is queryable from the capture file and settable too, and
conversions preserve un-rebased timestamps. Only rebasing when loading a
capture for replay.
* Non-integer DPI handling is fundamentally a broken concept, because UIs are
essentially pixel art with some vector drawing. Rounding down half fractions
seems to be a better tradeoff than rounding up or trying to render them as-is.
* We need to count the fake indirect subcommand *before* checking if we're in
range, otherwise replaying up to but not including the draw will miscount and
replay the draw itself.
baldurk