| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Blender did not support to input East Asian characters (Chinese, Japanese,
Korean) on macOS. This patch adds support for Japanese input, by implementing
the appropriate processing for the NSTextInputClient protocol.
Technical notes:
* The conversion candidate window is drawn by the input method program calling
`firstRectForCharacterRange`.
* The string before confirmation (called `composite` in blender) is handled in
the `setMarkedText` method called by the input method program.
* The string after confirmation (called `result` in the blender) is processed
in the `insertText` method called by the input method program.
Ref T51283
Differential Revision: https://developer.blender.org/D11695
|
|
In certain CMake configurations it was possible
that OCIO gave linker errors due to it thinking
it was using the shared library rather than the
static library we ship.
|
|
This patch fixes many minor spelling mistakes, all in comments or
console output. Mostly contractions like can't, won't, don't, its/it's,
etc.
Differential Revision: https://developer.blender.org/D11663
Reviewed by Harley Acheson
|
|
This adds preliminary VS 2022 support, since
there currently is no CMake version that
supports the VS2022 IDE only ninja support
was tested.
IDE support should work without any additional
changes as soon as an updated CMake becomes
available.
As VS2022 appears to keep binary compatibility
with earlier MSVC versions, the current SVN
libraries will work for this version.
|
|
This convention is no longer used for Blender's CMake files.
|
|
|
|
|
|
rB4f81b4b4ce29 mistakenly left out the changes
to platform_win32.cmake causing a linker error
when WITH_GMP and WITH_TBB_MALLOC_PROXY were on.
|
|
In Debian e.g. Clang is part of LLVM, so we need to also check its root
directory sometimes to find Clang files.
|
|
Due to the way we ship the CRT on windows TBB's
malloc proxy was unable to attach it self to
the memory management functions on windows 10.
This change moves ucrtbase.dll out of the blender.crt
folder and back into the main blender folder to side
step some undesirable behaviour on win10 making TBB
once more able to attach it self.
Having this work again, should give a speed
boost in memory allocation heavy workloads
such as mantaflow.
For details on how this only failed on Win10
see T88813
|
|
rB847579b42250 updated the TBB build script
which had some unintended consequences for
windows as the directory layout slightly
changed.
This change adjusts the builder to the new
structure, there are no version/functional
changes.
|
|
|
|
|
|
For 2.93 we bumped the minimum windows requirement
to windows 8.1, but did not do any clean-up of any
win 8/8.1 API usage we dynamically accessed though
LoadLibrary/GetProcAddress.
This patch bumps _WIN32_WINNT to 0x0603 (win 8.1)
and cleans up any API use that was accessed in a
more convoluted way than necessary
Differential Revision: https://developer.blender.org/D11331
Reviewed by: harley, nicholas_rishel
|
|
|
|
This patch fixes a long-standing complaint from users:
the console window shortly flashing when they start
blender.
This is done by adding a new executable called
blender-launcher.exe which starts blender.exe while
hiding the console.
Any command line parameters given to blender-launcher
will be passed on to blender.exe so it'll be a drop
in replacement.
Starting blender.exe on its own will still function as
a proper console app so no changes required here for
users that use blender for batch processing.
Notable changes:
Registering blender (-R switch) will now register
blender-launcher as the preferred executable.
This patch updates the installer and updates the
shortcuts to start blender-launcher.exe rather
than blender.exe
Differential Revision: https://developer.blender.org/D11094
Reviewed by: brecht, harley
|
|
Explicitly disable these, rather than relying on them not being found.
Also, don't duplicates the architectures list.
|
|
Includes fixes to misspelled function names.
Ref D11280
|
|
|
|
Make `CMAKE_OSX_DEPLOYMENT_TARGET` independent of buildbot settings and
always set to `OSX_MIN_DEPLOYMENT_TARGET`. That fixes the launch error
on OS older than buildbot's.
Remove unused `MACOSX_DEPLOYMENT_TARGET`.
Fix T88419
Diff D11323
|
|
Differential Revision: https://developer.blender.org/D10958
|
|
This changes the following items:
- package name is now `blender-3.0.0-git.09eb04c0a865-windows64`
rather than `blender-3.00.0-git.09eb04c0a865-windows64`
- Fix version resource for blender.exe not building
- Data directories are now `3.0\...` rather than `3.00\....`
- User prefs are now in:
`c:\Users\users\AppData\Roaming\Blender Foundation\Blender\3.0\`
rather than:
`c:\Users\users\AppData\Roaming\Blender Foundation\Blender\3.00\`
- Updating startup & preferences from previous release
has a special exception for 3.0 to check for 3.93 and older.
See T87532
Ref D10986
|
|
|
|
When Blender's minor version was single digits, it wasn't properly
extracted. Resolve by adding zero padding.
Issue raised by @harley in D10954.
|
|
'mypy --strict' passes without errors.
|
|
'mypy --strict' passes without errors.
|
|
- Remove `make_quicky` as on modern systems linking is the main
bottleneck, and there isn't such a gain from partial builds.
- Remove enum generator as `PyC_StringEnumItems` & `EnumPropertyItem`
are used in most places to access enums from Python, otherwise macros
are added via macros.
|
|
Tell `FindOSL.cmake` where to find the shader header files. These have
moved from `${LIBDIR}/osl/shaders` to `${LIBDIR}/osl/share/OSL/shaders`
when OSL was upgraded (T85365).
|
|
|
|
Correction in e5f0d176d4cfa020bfb4de78086007dcfd02e8f9
|
|
Only done in top level CMakeLists, and platform_apple.
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D10343
|
|
This enables ASAN support when used with VS 16.9
enable as usual in cmake with the WITH_COMPILER_ASAN
option, or when using make.bat just tag on `asan'
to the invocation, ie: `make lite 2019 asan`
MSVC: Asan support for 16.9
This enables ASAN support when used with VS 16.9
enable as usual in cmake with the WITH_COMPILER_ASAN
option, or when using make.bat just tag on `asan'
to the invocation, ie: `make lite 2019 asan`
Differential Revision: https://developer.blender.org/D7794
Reviewed By: brecht, sergey
|
|
|
|
Reviewed By: #platform_macos, brecht
Maniphest Tasks: T86579
Differential Revision: https://developer.blender.org/D10664
|
|
|
|
This adds CoreAudio as audio backend on macOS.
CoreAudio is the standard audio API on macOS.
Ref T86590
|
|
This adds WASAPI as audio backend on Windows.
WASAPI is the modern standard audio API on
Windows introduced with Windows Vista.
Ref T86590
|
|
This adds PulseAudio as audio backend on Linux.
PulseAudio is the main audio engine used on most,
if not all, Linux distributions today.
Ref T86590
|
|
Cleanup although it's harmless.
|
|
* Only try to find sse2neon if Neon detected
* Only run Neon support test once
|
|
The location of the shaders changed with OSL 1.11.10. This commit is therefore in addition to D10212.
@sybren With the latest SVN libraries, I am fairly certain there is a "OSL not found" in the CMake output. Can you check on Linux?
@LazyDodo Since you haven't pushed the new OSL libs yet, this should not be a problem on Windows. So this will only be needed whenever those land.
Reviewed By: LazyDodo
Differential Revision: https://developer.blender.org/D10552
|
|
Due to moving the code the test binary was incorrectly compiled with OpenMP
flags. Move setting of the OpenMP flags to the appropriate place.
|
|
Was disabled in rBc778fd981e63. Libraries have been updated in rBL62576.
|
|
New libs have not landed in the SVN repository. Once they are up, this commit will be reverted.
|
|
This bumps OSL to 1.11.10.0. OSL Has a new build time
dependency: Clang, and more importantly it expects
clang and llvm to share a library folder, which it
previously for us did not.
This patch changes:
-OSL Update to 1.11.10.0
-refactor the llvm/clang/clang-tools-extra builds into the llvm
build using the llvm-project tarball for building that has all
of the subprojects in it.
-update ispc/openmp builds since clang no longer its own dependency
and they have to depend on the llvm build now.
-Update the windows builder to use the 64 bit host tools since it
ran out of ram linking clang
-Since OSL now needs clang to link successfully a findclang.cmake
has been provided for linux/OSX
Differential Revision: https://developer.blender.org/D10212
Reviewed By: brecht, sebbas, sybren
|
|
This updates platform/platform_win32.cmake to support
both the old and new library names for OpenXR.
The new version links against one additional system
library and the debug library filename changed ever
so slightly.
This is a temporary workaround and can be removed
once the new lib versions have landed.
|
|
Rather than hardcoding the lib names, read
boosts version.hpp and extract the version
from there.
This will make it easier to land lib changes
in the near future.
|
|
Latest Xcode takes up 15GB, command line tools are only 1.2GB.
|
