Previously, input streams created by AndroidDocument instances did not
implement setPosition, so they were not useful for reading some file
formats, such as WAV.
Due to limitations of the Java InputStream interface, seeking backwards
in a stream requires creating a whole new stream and seeking from the
beginning, so it could be quite slow.
This restores the functionality of JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS.
Using this preprocessor flag may avoid Core Graphics rendering much larger regions than
necessary, but the small regions that are rendered will likely be rendered slower.
Whether using this flag improves or degrades the performance of your rendering overall
will be specific to each application.
Previously enabling JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS was ineffective
from versions of macOS around 10.13, but enabling it didn't have any negative impact on
performance. Now enabling JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS may result
in slower rendering.
With this patch applied, the DemoRunner should build under MinGW, and be
(nearly) feature-complete compared to the MSVC build.
Specifically, when building with MinGW:
- Adds support for accessibility
- Fixes build issues in the juce_video module
- Fixes a link issue in the VST3 wrapper when VST3_CAN_REPLACE_VST2 is
defined
- Adds support for the new-style native FileChooser
- Tidies up some other low-severity warnings
Known issues:
- Direct2D rendering is still not supported when building with MinGW due
to ABI compatibilities.
The Apple threading documentation [^1] says the following:
> The second argument to pthread_setschedparam is the desired policy,
which can currently be one of SCHED_FIFO (first in, first out),
SCHED_RR (round-robin), or SCHED_OTHER. The SCHED_OTHER policy is
generally used for extra policies that are specific to a given
operating system, and should thus be avoided when writing portable
code.
This appears to differ from the policy semantics on Linux and BSD, where
FIFO and RR are both explicitly real-time policies.
Therefore, on Linux/BSD we only enable the RR policy if the requested
priority is 8 or higher. Meanwhile, on macOS, we map all thread
priorities (0 - 10) onto the RR policy with an appropriate priority.
[^1]: https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/KernelProgramming/scheduler/scheduler.html
The Apple threading documentation [^1] says the following:
> The second argument to pthread_setschedparam is the desired policy,
which can currently be one of SCHED_FIFO (first in, first out),
SCHED_RR (round-robin), or SCHED_OTHER. The SCHED_OTHER policy is
generally used for extra policies that are specific to a given
operating system, and should thus be avoided when writing portable
code.
This appears to differ from the policy semantics on Linux and BSD, where
FIFO and RR are both explicitly real-time policies.
Therefore, on Linux/BSD we only enable the RR policy if the requested
priority is 8 or higher. Meanwhile, on macOS, we map all thread
priorities (0 - 10) onto the RR policy with an appropriate priority.
[^1]: https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/KernelProgramming/scheduler/scheduler.html