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.
Several things are accomplished in this commit, including:
- Use OIIO instead of our own functions for pixel format conversions
(cleaner code/less for us to maintain)
- Fold all PixelService functions into the PixelFormat class
(cleaner code)
- Moved OpenGL pixel definitions to OpenGL classes and out of the
global classes.
- Add support for RGB buffers as well as RGBA (optimization)
Many file systems become inefficient with a lot of files in the same directory.
To solve this we use a semi-arbitrary system to split up all cache files into
several folders to keep things performant.
Fixes a number of playback stuttering and general UI lag issues by setting all
background tasks to IdlePriority rather than LowPriority. While it was assumed
LowPriority tasks would always get scheduled below NormalPriority (e.g. main
thread) tasks, it turns out this is not always the case. If the background tasks
start consuming a lot of CPU cycles, the scheduler may use "dynamic scheduling"
to schedule them above the main thread regardless leading to UI lag. This is
apparently the case for all thread priorities apart from IdlePriority, which
is allegedly a special case where threads are *only* scheduled when other
threads aren't busy ensuring the main thread stays responsive.
functions
Indexing is a lengthy process and had a high chance of getting RenderWorkers
stuck doing it rather than being responsive to cache requests. This commit
introduces a system where workers never index media, but instead signal that
media is not ready to their RenderBackends which ensure that the media gets
indexed and re-queues the affected frames when those indexes are ready.
than overwritten on some platforms
Despite the fact we don't actually do any reading here, using
QFile::WriteOnly on its own will truncate the file to 0 bytes which is
undesirable. The documentation says QFile::ReadOnly, Append or NewOnly
will prevent this. NewOnly won't work and reads are unnecessary, so
Append was used initially. However on some platforms, Append will _only_
allow writing at the end of the file (ignoring the seek() function)
meaning bytes won't be written where they're meant to be (this behavior
happens on Linux and not on Windows, the platform discrepancy is likely
a Qt bug). Using ReadWrite instead, despite not reading anything,
prevents truncation and allows for writing not at the end of the file.
context
More intuitive code flow and allows the user to undock the viewer (which
forcibly destroys and recreates the context) and the viewer will handle
creation of the new texture in said new context.
itsmattkc