9ae52f3d7a
Problem description
===================
Firstly, the linked-list of pending presentations acted as a stack
(FILO). If the swap chain thread and main thread processed frames at
varying rates, then the following sequence of events was possible:
Main thread Swap chain thread Queue state
---------------------------------------------------------
Push frame (1) [1]
Push frame (2) [2, 1]
Pop frame (2) [1]
Push frame (3) [3, 1]
Pop frame (3) [1]
Pop frame (1) [] <-- Out of sequence!
Secondly, the swap chain's sequential flip model can only maintain a
valid back-buffer state as long as the list of dirty rects is correct,
and every pixel within the dirty rects is painted incrementally.
In the example above, if the main thread were to produce two frames
before the swap chain thread could present any frame, then presenting
*only* the frame 2 (skipping frame 1) may produce incorrect results when
combined with the existing back buffer. This is because regions updated
in frame 1 may not be updated in frame 2, so regions *only* updated in
frame 1 will be omitted from the back buffer.
Mitigation
==========
This patch removes the old stack of presentations and replaces it with a
slightly more complex mechanism that tracks two different Presentation
objects. At any time, up to one Presentation may be in use by the swap
chain thread (i.e. actively presenting), up to one Presentation may be
accumulating updated/dirty regions (i.e. painting), and up to one region
may be ready, awaiting display.
This scheme resolves the first issue described above by ensuring that
old frame data is not kept around. There is never more than one frame
awaiting display, which means that if the swap chain thread attempts to
display twice in a row (before the main thread produces a new frame),
the second attempt will be a no-op.
The second issue is resolved by accumulating changes into a single
Presentation whenever the main thread produces two or more frames in a
row. If there is already a 'ready' Presentation when the main thread
finishes painting, then all updated regions from the newest Presentation
will be added to the 'ready' Presentation, rather than replacing it.
When the swap chain thread is ready to present, it will therefore see
the result of all the accumulated Presentations produced by the main
thread, instead of just the newest Presentation.
|
||
|---|---|---|
| .github | ||
| docs | ||
| examples | ||
| extras | ||
| modules | ||
| .clang-tidy | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| BREAKING_CHANGES.md | ||
| CHANGE_LIST.md | ||
| CMakeLists.txt | ||
| CODE_OF_CONDUCT.md | ||
| LICENSE.md | ||
| README.md | ||
JUCE is an open-source cross-platform C++ application framework for creating desktop and mobile applications, including VST, VST3, AU, AUv3, AAX and LV2 audio plug-ins and plug-in hosts. JUCE can be easily integrated with existing projects via CMake, or can be used as a project generation tool via the Projucer, which supports exporting projects for Xcode (macOS and iOS), Visual Studio, Android Studio, and Linux Makefiles as well as containing a source code editor.
Getting Started
The JUCE repository contains a master and develop branch. The develop branch contains the latest bug fixes and features and is periodically merged into the master branch in stable tagged releases (the latest release containing pre-built binaries can be also downloaded from the JUCE website).
JUCE projects can be managed with either the Projucer (JUCE's own project-configuration tool) or with CMake.
The Projucer
The repository doesn't contain a pre-built Projucer so you will need to build it for your platform - Xcode, Visual Studio and Linux Makefile projects are located in extras/Projucer/Builds (the minimum system requirements are listed in the minimum system requirements section below). The Projucer can then be used to create new JUCE projects, view tutorials and run examples. It is also possible to include the JUCE modules source code in an existing project directly, or build them into a static or dynamic library which can be linked into a project.
For further help getting started, please refer to the JUCE documentation and tutorials.
CMake
Version 3.22 or higher is required. To use CMake, you will need to install it, either from your system package manager or from the official download page. For comprehensive documentation on JUCE's CMake API, see the JUCE CMake documentation. For examples which may be useful as starting points for new CMake projects, see the CMake examples directory.
Building Examples
To use CMake to build the examples and extras bundled with JUCE, simply clone JUCE and then run the following commands, replacing "DemoRunner" with the name of the target you wish to build.
cd /path/to/JUCE
cmake . -B cmake-build -DJUCE_BUILD_EXAMPLES=ON -DJUCE_BUILD_EXTRAS=ON
cmake --build cmake-build --target DemoRunner
Minimum System Requirements
Building JUCE Projects
- C++ Standard: 17
- macOS/iOS: Xcode 12.4 (Intel macOS 10.15.4, Apple Silicon macOS 11.0)
- Windows: Visual Studio 2019 (Windows 10)
- Linux: g++ 7.0 or Clang 6.0 (for a full list of dependencies, see here).
- Android: Android Studio (NDK 26) on Windows, macOS or Linux
Deployment Targets
- macOS: macOS 10.11
- Windows: Windows 10
- Linux: Mainstream Linux distributions
- iOS: iOS 12
- Android: Android 5 - Lollipop (API Level 21)
Contributing
Please see our contribution guidelines.
Licensing
See LICENSE.md for licensing and dependency information.
AAX Plug-Ins
AAX plug-ins need to be digitally signed using PACE Anti-Piracy's signing tools before they will run in commercially available versions of Pro Tools. These tools are provided free of charge by Avid. Before obtaining the signing tools, you will need to use a special build of Pro Tools, called Pro Tools Developer, to test your unsigned plug-ins. The steps to obtain Pro Tools Developer are:
- Sign up as an AAX Developer here.
- Request a Pro Tools Developer Bundle activation code by sending an email to devauth@avid.com.
- Download the latest Pro Tools Developer build from your Avid Developer account.
When your plug-ins have been tested and debugged in Pro Tools Developer, and you are ready to digitally sign them, please send an email to audiosdk@avid.com with the subject "PACE Eden Signing Tools Request". You need to include an overview of each plug-in along with a screen recording showing the plug-in running in Pro Tools Developer, with audio if possible.
Please also include the following information:
- Company name
- Admin full name
- Telephone number
Once the request is submitted, PACE Anti-Piracy will contact you directly with information about signing your plug-ins. When the plug-ins have been signed, you are free to sell and distribute them. If you are interested in selling your plug-ins on the Avid Marketplace, please send an email to audiosdk@avid.com.