When creating a new window from a duplicated area - by shift-dragging
on corner action zones - on the Windows platform the resulting window
is initially unresponsive. This patch fixes this by releasing the parent
window's mouse capture.
See D14085 for more details.
Differential Revision: https://developer.blender.org/D14085
Reviewed by Ray Molenkamp
Windows IME: Fix duplicated initial character when entering numbers
while in Chinese full width character mode.
See D14354 for more details.
Differential Revision: https://developer.blender.org/D14354
Reviewed by Brecht Van Lommel
Mousemove events are sent to windows.
In Windows OS, almost all mousemove events are sent to the window whose
mouse cursor is over.
On MacOS, the window with mousemove events is always the active window.
It doesn't matter if the mouse cursor is inside or outside the window.
So, in order for non-active windows to also have events,
`WM_window_find_under_cursor` is called to find those windows and send
the same events.
The problem is that to find the window, `WM_window_find_under_cursor`
only has the mouse coordinates available, it doesn't differentiate
which monitor these coordinates came from.
So the mouse on one monitor may incorrectly send events to a window on
another monitor.
The solution used is to use a native API on Mac to detect the window
under the cursor.
For Windows and Linux nothing has changed.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D14197
This fixes T93051, T76405 and maybe others.
Characters like '²', '<' are not recognized in Blender's shortcut keys.
And sometimes simple buttons like {key .} and {key /} on the Windows
keyboard, although the symbol is "known", Blender also doesn't
detect for shortcuts.
For Windows, some of the symbols represented by `VK_OEM_[1-8]` values,
depending on the language, are not mapped by Blender.
On Mac there is a fallback reading the "actual character value of the
'remappable' keys". But sometimes the character is not mapped either.
On Windows, the solution now mimics the Mac and tries to read the button's
character as a fallback.
For unmapped characters ('²', '<', '\''), now another value is chosen as a
substitute.
More "substitutes" may be added over time.
Differential Revision: https://developer.blender.org/D14149
Helps with building against different OpenXR SDK versions (i.e. for
downstream builds that require specific versions), as the extension was
only defined since OpenXR 1.0.22.
This fixes VR pink screen issues when using the DirectX backend, caused
by `wglDXRegisterObjectNV()` failing to register the shared
OpenGL-DirectX render buffer. The issue is mainly present on AMD
graphics, however, there have been reports on NVIDIA as well.
A limited workaround for the SteamVR runtime (AMD only) was provided
in rB82ab2c167844, however this patch provides a more complete solution
that should apply to all OpenXR runtimes. For example, with this patch,
the Windows Mixed Reality runtime that exclusively uses DirectX can now
be used with AMD graphics cards.
Implementation-wise, a `GL_TEXTURE_2D` render target is used as a
fallback for the shared OpenGL-DirectX resource in the case that
registering a render buffer (`GL_RENDERBUFFER`) fails. While using a
texture render target may be less optimal than a render buffer, it
enables proper display in VR using the OpenGL/DirectX interop (tested
on AMD Vega 64).
Reviewed By: Severin
Differential Revision: https://developer.blender.org/D14100
When using a RGBA16 (`GL_RGBA16`, `DXGI_FORMAT_R16G16B16A16_UNORM`)
swapchain format with Quest 2, no image is presented to the headset.
This can occur when using the SteamVR runtime with an AMD graphics card
(ex. T95374).
Workaround is to move this format after the Quest 2-compatible RGBA16F
formats in the candidates list so that the RGBA16F formats are chosen
instead.
Reviewed By: Severin
Differential Revision: https://developer.blender.org/D14024
Crash was caused since the function pointers
`s_xrGetOpenGLGraphicsRequirementsKHR_fn`/
`s_xrGetD3D11GraphicsRequirementsKHR_fn` were static and were not
updated with the correct proc address after being set the first time.
As stated in the OpenXR spec: "function pointers returned by
xrGetInstanceProcAddr using one XrInstance may not be valid when used
with objects related to a different XrInstance".
Although it would seem reasonable that the proc address would not
change if the instance was the same (hence the `static XrInstance s_instance;`),
in testing, repeated calls to `xrGetInstanceProcAddress()`
with the same instance still can result in changes (at least for the
SteamVR runtime) so the workaround is to simply set the function pointers
every time, essentially trivializing their `static` designations.
Reviewed By: Severin
Maniphest Tasks: T94268
Differential Revision: https://developer.blender.org/D14023
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
This is almost always meaningless as most code has changed
since the comment was added. Besides this, version control can be used
to check if/when a file was modified.
Some cases of this were kept when they contain details
about the original copyright holder.
GHOST_ISystem::toggleConsole had a somewhat misleading name
it could be fed 4 different values, so it was not as much a
toggle as a set console window state.
This change renames `toggleConsole` to a more appropriately
named `setConsoleWindowState` and replaces the integer it had
to an enum so it's easy to tell what is being asked of it at
the call site.
Reviewed By: LazyDodo
Differential Revision: https://developer.blender.org/D14020
If the console was hidden on windows, it would
be made visible during shutdown in an effort
not hide a potentially active interactive console
session. This however did not take in account
if blender was actually launched from an interactive
console causing the console window to briefly flash
during shutdown even when launched from the new
launcher, the brief flash concerned some users.
This change adjusts the behaviour to restore the
console only when blender was started from the
console.
Reviewed By: LazyDodo
Differential Revision: https://developer.blender.org/D14016
Show a more instructive error message for users who have plugged
multiple monitors into multiple display adapters. And do not exit
if unable to open a child window when in this state.
See D13885 for more details
Differential Revision: https://developer.blender.org/D13885
Reviewed by Ray Molenkamp
Allow Windows IME Pinyin, when in Chinese mode, to use numpad decimal
key to enter decimal point.
See D13902 for more details.
Differential Revision: https://developer.blender.org/D13902
Reviewed by Brecht Van Lommel
Initialize m_Bar, m_dropTarget, & m_hWnd members of GHOST_WindowWin32
in constructor's member initializer list. This ensures they are are
set or NULL in destructor if constructor does not complete.
See D13886 for more details.
Differential Revision: https://developer.blender.org/D13886
Reviewed by Jesse Yurkovich
This reverts commit 086f191169.
There was apparently a problem using APPEND which wasn't referenced
in the commit log.
Added comment noting the reason for the discrepancy.
This was already done for APPLE & WIN32, which would
reference these libraries twice.
Now append BROTLI_LIBRARIES to FREETYPE_LIBRARIES when they're
required for linking.
No functional changes as all references to FREETYPE_LIBRARIES also
used BROTLI_LIBRARIES.
The UI team requested adding woff2 support to freetype.
this required a new dependency brotli.
This changes adds brotili to the builder and bumps
freetype to version 2.11.0
As freetype now depends on other libraries, for consistency
all use of ${FREETYPE_LIBRARY} in cmake has been updated to
use ${FREETYPE_LIBRARIES} adjustments have been made in the
windows platform file, all other platforms use cmake's
FindFreeType.cmake which already sets this variable.
reviewed by: brecht
Differential Revision: https://developer.blender.org/D13448
This patch implements the vector types (i.e:`float2`) by making heavy
usage of templating. All vector functions are now outside of the vector
classes (inside the `blender::math` namespace) and are not vector size
dependent for the most part.
In the ongoing effort to make shaders less GL centric, we are aiming
to share more code between GLSL and C++ to avoid code duplication.
####Motivations:
- We are aiming to share UBO and SSBO structures between GLSL and C++.
This means we will use many of the existing vector types and others
we currently don't have (uintX, intX). All these variations were
asking for many more code duplication.
- Deduplicate existing code which is duplicated for each vector size.
- We also want to share small functions. Which means that vector
functions should be static and not in the class namespace.
- Reduce friction to use these types in new projects due to their
incompleteness.
- The current state of the `BLI_(float|double|mpq)(2|3|4).hh` is a
bit of a let down. Most clases are incomplete, out of sync with each
others with different codestyles, and some functions that should be
static are not (i.e: `float3::reflect()`).
####Upsides:
- Still support `.x, .y, .z, .w` for readability.
- Compact, readable and easilly extendable.
- All of the vector functions are available for all the vectors types
and can be restricted to certain types. Also template specialization
let us define exception for special class (like mpq).
- With optimization ON, the compiler unroll the loops and performance
is the same.
####Downsides:
- Might impact debugability. Though I would arge that the bugs are
rarelly caused by the vector class itself (since the operations are
quite trivial) but by the type conversions.
- Might impact compile time. I did not saw a significant impact since
the usage is not really widespread.
- Functions needs to be rewritten to support arbitrary vector length.
For instance, one can't call `len_squared_v3v3` in
`math::length_squared()` and call it a day.
- Type cast does not work with the template version of the `math::`
vector functions. Meaning you need to manually cast `float *` and
`(float *)[3]` to `float3` for the function calls.
i.e: `math::distance_squared(float3(nearest.co), positions[i]);`
- Some parts might loose in readability:
`float3::dot(v1.normalized(), v2.normalized())`
becoming
`math::dot(math::normalize(v1), math::normalize(v2))`
But I propose, when appropriate, to use
`using namespace blender::math;` on function local or file scope to
increase readability.
`dot(normalize(v1), normalize(v2))`
####Consideration:
- Include back `.length()` method. It is quite handy and is more C++
oriented.
- I considered the GLM library as a candidate for replacement. It felt
like too much for what we need and would be difficult to extend / modify
to our needs.
- I used Macros to reduce code in operators declaration and potential
copy paste bugs. This could reduce debugability and could be reverted.
- This touches `delaunay_2d.cc` and the intersection code. I would like
to know @howardt opinion on the matter.
- The `noexcept` on the copy constructor of `mpq(2|3)` is being removed.
But according to @JacquesLucke it is not a real problem for now.
I would like to give a huge thanks to @JacquesLucke who helped during this
and pushed me to reduce the duplication further.
Reviewed By: brecht, sergey, JacquesLucke
Differential Revision: https://developer.blender.org/D13791
This patch implements the vector types (i.e:float2) by making heavy
usage of templating. All vector functions are now outside of the vector
classes (inside the blender::math namespace) and are not vector size
dependent for the most part.
In the ongoing effort to make shaders less GL centric, we are aiming
to share more code between GLSL and C++ to avoid code duplication.
Motivations:
- We are aiming to share UBO and SSBO structures between GLSL and C++.
This means we will use many of the existing vector types and others we
currently don't have (uintX, intX). All these variations were asking
for many more code duplication.
- Deduplicate existing code which is duplicated for each vector size.
- We also want to share small functions. Which means that vector functions
should be static and not in the class namespace.
- Reduce friction to use these types in new projects due to their
incompleteness.
- The current state of the BLI_(float|double|mpq)(2|3|4).hh is a bit of a
let down. Most clases are incomplete, out of sync with each others with
different codestyles, and some functions that should be static are not
(i.e: float3::reflect()).
Upsides:
- Still support .x, .y, .z, .w for readability.
- Compact, readable and easilly extendable.
- All of the vector functions are available for all the vectors types and
can be restricted to certain types. Also template specialization let us
define exception for special class (like mpq).
- With optimization ON, the compiler unroll the loops and performance is
the same.
Downsides:
- Might impact debugability. Though I would arge that the bugs are rarelly
caused by the vector class itself (since the operations are quite trivial)
but by the type conversions.
- Might impact compile time. I did not saw a significant impact since the
usage is not really widespread.
- Functions needs to be rewritten to support arbitrary vector length. For
instance, one can't call len_squared_v3v3 in math::length_squared() and
call it a day.
- Type cast does not work with the template version of the math:: vector
functions. Meaning you need to manually cast float * and (float *)[3] to
float3 for the function calls.
i.e: math::distance_squared(float3(nearest.co), positions[i]);
- Some parts might loose in readability:
float3::dot(v1.normalized(), v2.normalized())
becoming
math::dot(math::normalize(v1), math::normalize(v2))
But I propose, when appropriate, to use
using namespace blender::math; on function local or file scope to
increase readability. dot(normalize(v1), normalize(v2))
Consideration:
- Include back .length() method. It is quite handy and is more C++
oriented.
- I considered the GLM library as a candidate for replacement.
It felt like too much for what we need and would be difficult to
extend / modify to our needs.
- I used Macros to reduce code in operators declaration and potential
copy paste bugs. This could reduce debugability and could be reverted.
- This touches delaunay_2d.cc and the intersection code. I would like to
know @Howard Trickey (howardt) opinion on the matter.
- The noexcept on the copy constructor of mpq(2|3) is being removed.
But according to @Jacques Lucke (JacquesLucke) it is not a real problem
for now.
I would like to give a huge thanks to @Jacques Lucke (JacquesLucke) who
helped during this and pushed me to reduce the duplication further.
Reviewed By: brecht, sergey, JacquesLucke
Differential Revision: http://developer.blender.org/D13791
Removal of unused tmp member of GHOST_TEventImeData. Not used now,
nor was it used by the commit that added it to begin with.
Differential Revision: https://developer.blender.org/D11799
Reviewed by Ray Molenkamp
Treat "/" as a key that should be evaluated by the Win IME system when
the input language is Chinese. This fixes a duplication of the input
character and results in the expected output of a Chinese wide comma.
See D13771 for more details.
Differential Revision: https://developer.blender.org/D13771
Reviewed by Brecht Van Lommel
