c24d1a17a7
This change intends to address a bug observed only on Windows 10 with a display scale factor of 125%. When the native titlebar is enabled, and the window's border-resizer is used to resize the window slowly the with mouse, the client area of the window may move to the wrong location, or be drawn with some areas obscured/clipped. This is especially observable when resizing the WidgetsDemo to its smallest size, and then dragging the right border a single pixel to the right. On my computer, this consistently causes the client area to display at the wrong location. I haven't been able to find any obvious bug in JUCE that might cause this behaviour. In particular, it seems that the window begins displaying incorrectly *before* the window ever actually resizes. During the resize, the system sends events (WM_SIZING and WM_WINDOWPOSCHANGING) to the window, and according to the documentation, the window may modify the message parameters in order to constrain the new window size. When running on a scaled display, JUCE attempts to map the logical client area size to a sensible size in physical pixels, and uses the sizing messages to enforce this size requirement. In the case of the broken window rendering, the system requests a new window size, which JUCE rejects. The window's display state doesn't change, so the swap chain does not resize, and the swap chain does not present. Put another way, the broken rendering happens *independently* of JUCE modifying the swap chain in any way. Therefore, I believe that the bug is introduced elsewhere, potentially by Windows itself. I also checked to see whether the issue could be caused by mishandling of the NCCALCSIZE message, which is normally used to configure the relative positions of the client and nonclient areas. However, in the buggy case, NCCALCSIZE is not sent until *after* the first 'broken' frame is painted - and even then, the implementation immediately falls back to DefWindowProc. Given that the issue appears to be a bug in Windows, the proposed change is a workaround, rather than a true fix. It appears as though the problem goes away when WM_WINDOWPOSCHANGING does not modify the requested bounds. Therefore, for windows with native titlebars, we rely on the constraints to be applied in WM_SIZING only, when sizing the window in a sizemove gesture. |
||
|---|---|---|
| .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 (x86_64, Arm64)
- Windows: Windows 10 (x86_64, x86, Arm64, Arm64EC)
- Linux: Mainstream Linux distributions (x86_64, Arm64/aarch64, (32 bit Arm systems like armv7 should work but are not regularly tested))
- iOS: iOS 12 (Arm64, Arm64e, x86_64 (Simulator))
- Android: Android 5 - Lollipop (API Level 21) (arm64-v8a, armeabi-v7a, x86_64, x86)
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.