The macro defined namespaces confused the hell out of lupdate and more or less broke translations permanently. Looks like the only way we can do it is to have a hardcoded namespace, which goes against my instinct, but honestly how likely is it that we'll change the namespace anyway (I guess forks might want to do it, but that's their problem ;) )
QApplication is designed for GUI/widget programs and thus fails to launch
if no window system is available. For a true headless mode, we must swap
out with QCoreApplication. However, what complicates this is that
QCommandLineParser - the class we use to determine whether we should run
in GUI mode or not - requires an active application instance to work.
This creates an unfortunate catch-22 that ultimately ended in writing a
custom command line parser.
Now we can correctly swap out with QCoreApplication, however this has
exposed other issues regarding functions that unnecessarily rely on QWidget
functions. So they'll need to be sorted out eventually.
First attempt at automated out-of-process crash reporting. Have only
updated AppVeyor script so far, so if this works (which it won't), it'll
only work on Windows.
This seems to cause issues on various platforms and isn't required a lot of the
time:
* macOS doesn't need this since the HiDPI setting is in the bundle's Info.plist
* Windows doesn't need this, in fact it seems to make fractional HiDPI worse
* Linux... who knows how to get HiDPI working on Linux
The GLSL shaders are written in GLSL 1.10 even though the OpenGL standard is
set to OpenGL ES 3.2 Core. Many platforms allow this but some platforms don't.
For standards compliance, it's probably a good idea in the future to upgrade
the shaders to 3.2, but for now we'll use 3.2 Compatibility which will allow the
GLSL 1.10 shaders to compile.
This function was noticeably lagging the main thread while caching. The
cause was OpenEXR's internal thread pool competing with our main
thread. Since we have our own system of worker threads, its thread pool
was unnecessary for caching, however for normal playback it was a useful
optimization. Unfortunately OIIO (which we were using to save EXRs)
didn't provide quite enough control over OpenEXR's threading behavior
(only providing control for over the global thread pool and not on
a per-image basis), so for caching we've switched to using OpenEXR
directly. This has noticeably sped up the main thread while causing no
noticeable slowdown to the caching process.
The encoder was moved to its own thread and will transcode the PCM from the
audio renderer into the chosen codec while the video frames are still
received. The implementation isn't perfect and could use some cleaning up, but
it is functional at the moment.
itsmattkc