The only difference between `GPU_SHADER_2D_LINE_DASHED_UNIFORM_COLOR`
and `GPU_SHADER_3D_LINE_DASHED_UNIFORM_COLOR` is that in the vertex
shader the 2D version uses `vec4(pos, 0.0, 1.0)` and the 3D version
uses `vec4(pos, 1.0)`.
But VBOs with 2D attributes work perfectly in shaders that use 3D
attributes. Components not specified are filled with components from
`vec4(0.0, 0.0, 0.0, 1.0)`.
So there is no real benefit to having two different shader versions.
The only real difference between `GPU_SHADER_2D_SMOOTH_COLOR` and
`GPU_SHADER_3D_SMOOTH_COLOR` is that in the vertex shader the 2D
version uses `vec4(pos, 0.0, 1.0)` and the 3D version uses
`vec4(pos, 1.0)`.
But VBOs with 2D attributes work perfectly in shaders that use 3D
attributes. Components not specified are filled with components from
`vec4(0.0, 0.0, 0.0, 1.0)`.
So there is no real benefit to having two different shader versions.
This will simplify porting shaders to python as it will not be
necessary to use a 3D and a 2D version of the shaders.
In python the new name for '2D_SMOOTH_COLOR' and '3D_SMOOTH_COLOR'
is 'SMOOTH_COLOR', but the old names still work for backward
compatibility.
The only real difference between `GPU_SHADER_2D_IMAGE` and
`GPU_SHADER_3D_IMAGE` is that in the vertex shader the 2D
version uses `vec4(pos, 0.0, 1.0)` and the 3D version uses
`vec4(pos, 1.0)`.
But VBOs with 2D attributes work perfectly in shaders that use 3D
attributes. Components not specified are filled with components from
`vec4(0.0, 0.0, 0.0, 1.0)`.
So there is no real benefit to having two different shader versions.
This will simplify porting shaders to python as it will not be
necessary to use a 3D and a 2D version of the shaders.
In python the new name for '2D_IMAGE' and '3D_IMAGE'
is 'IMAGE', but the old names still work for backward
compatibility.
The only real difference between `GPU_SHADER_2D_UNIFORM_COLOR` and
`GPU_SHADER_3D_UNIFORM_COLOR` is that in the vertex shader the 2D
version uses `vec4(pos, 0.0, 1.0)` and the 3D version uses
`vec4(pos, 1.0)`.
But VBOs with 2D attributes work perfectly in shaders that use 3D
attributes. Components not specified are filled with components from
`vec4(0.0, 0.0, 0.0, 1.0)`.
So there is no real benefit to having two different shader versions.
This will simplify porting shaders to python as it will not be
necessary to use a 3D and a 2D version of the shaders.
In python the new name for '2D_UNIFORM_COLOR'' and '3D_UNIFORM_COLOR'
is 'UNIFORM_COLOR', but the old names still work for backward
compatibility.
Differential Revision: https://developer.blender.org/D15836
When saving, the default file name is "untitled" regardless of
selected language. This can be translated, like many graphical
applications do.
This applies to:
- blend file
- alembic file
- collada file
- obj file
- usd file
- rendered image
- grease pencil export
- subtitles export
- other Python exports through ExportHelper
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D15868
While missing the break before a default that only breaks isn't
an error, it means adding new cases needs to remember to add the
break for an existing case, changing the default case will also
result in an unintended fall-through.
Also avoid `default:;` and add an explicit break.
Since [0] notifiers were cleared and left in the queue, while harmless
it meant the call to remove the notifier from the set was redundant.
Now set aside a category to tag notifiers as having been cleared and
skip them entirely.
[0]: 0aaff9a07d
The blendfile_liblink and blendfile_io python tests in debug fired an
assert that WMWinMan object was in Main database, but not in the ID
name map. This was caused by wm_window_match_do going into case 3
there: the new WM list is completely empty, the old list is not empty,
and it was directly using the old/current list (via
wm_window_match_keep_current_wm function), without actually
registering/validating the objects in it through the name map.
Reviewed By: Bastien Montagne
Differential Revision: https://developer.blender.org/D15787
The blendfile_liblink and blendfile_io python tests in debug fired an
assert that WMWinMan object was in Main database, but not in the ID
name map. This was caused by wm_window_match_do going into case 3
there: the new WM list is completely empty, the old list is not empty,
and it was directly using the old/current list (via
wm_window_match_keep_current_wm function), without actually
registering/validating the objects in it through the name map.
Reviewed By: Bastien Montagne
Differential Revision: https://developer.blender.org/D15787
This makes workspaces more translatable:
- New Workspace menu
- header
- preset menus
- preset entries
- workspace names upon factory file template load
- new workspace name upon workspace addition
To properly translate those names, an extraction function for
workspace names from app templates was added as well.
(Do not do anything when loading a user-saved file!)
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D15727
Use a GSet to check for duplicate notifiers, for certain Python scripts
checking for duplicate notifiers added considerable overhead.
This is an alternative to D15129 with fewer chances to existing logic.
Pressing escape when rendering a viewport animation would
access the freed even and crash (with ASAN enabled).
Always check the context's window before the event as this is a signal
a file was loaded or the window was closed (and it's events freed).
Use an off-screen buffer for the screen-shot operator.
Reading from the front-buffer immediately after calling swap-buffers
failed for GHOST/Wayland in some cases.
While EGL can request to preserve the front-buffer while drawing,
this isn't always supported. So workaround the problem by avoiding
use of the front-buffer entirely.
With this patch true headless OpenGL rendering is now possible on Linux.
It changes the logic of the WITH_HEADLESS build flag.
The headless backend is now always available with regular builds and
Blender will try to fall back to it if it fails to initialize other
backends while in background mode.
The headless backend only works on Linux as EGL is not used on Mac or Windows.
libepoxy does support windows and mac, so this can perhaps be remedied in the future.
Reviewed By: Brecht, Jeroen, Campbell
Differential Revision: http://developer.blender.org/D15555
GPU_exit is now expected to run within an active GPU context.
Also run BLF_exit and IMB_exit first they can use GPU resources and gave
ASAN errors. And remove redundant GPU_shader_free_builtin_shaders already
handled by GPU_exit.
Always use modifier keys from the active window, as changes to the
modifiers aren't sent to inactive windows.
Also resolves modifier keys being lost on window de-activation.
Activating the window again would check the previous state of the
modifiers which was always cleared as of [0],
now clearing is no longer needed.
[0]: 472595f1d3
Currently, the compositor can be disabled using the WITH_COMPOSITOR
build option. Since, we intent to always build the realtime compositor,
we need to make the distinction between both compositors clear.
So this patch renames the option to WITH_COMPOSITOR_CPU. Additionally,
the check for the option was moved inside the compositor modules' own
CMake file in preparation for the realtime compositor code.
Differential Revision: https://developer.blender.org/D15622
Reviewed By: Jeroen Bakker, Ray Molenkamp
NOTE: This is committed to the 3.3 branch as part of D15606, which we
decided should go to this release still (by Bastien, Dalai and me). That
is because these are important usability fixes/improvements to have for
the LTS release.
Adds `rna_path.cc` and `RNA_path.h`.
`rna_access.c` is a quite big file, which makes it rather hard and
inconvenient to navigate. RNA path functions form a nicely coherent unit
that can stand well on it's own, so it makes sense to split them off to
mitigate the problem. Moreover, I was looking into refactoring the quite
convoluted/overloaded `rna_path_parse()`, and found that some C++
features may help greatly with that. So having that code compile in C++
would be helpful to attempt that.
Differential Revision: https://developer.blender.org/D15540
Reviewed by: Brecht Van Lommel, Campbell Barton, Bastien Montagne
Adds `rna_path.cc` and `RNA_path.h`.
`rna_access.c` is a quite big file, which makes it rather hard and
inconvenient to navigate. RNA path functions form a nicely coherent unit
that can stand well on it's own, so it makes sense to split them off to
mitigate the problem. Moreover, I was looking into refactoring the quite
convoluted/overloaded `rna_path_parse()`, and found that some C++
features may help greatly with that. So having that code compile in C++
would be helpful to attempt that.
Differential Revision: https://developer.blender.org/D15540
Reviewed by: Brecht Van Lommel, Campbell Barton, Bastien Montagne
Add a util function to check that content of a given Main and the
namemaps in it are consistent.
Add some asserts calling this check after file read, and after some
override operations.
The ISMOUSE macro was used in situations only button events
needed to be checked.
The only functional difference would be MOUSEMOVE events were
previously accepted for these checks.
Drop events ignored the cursor coordinates, under the assumption that
cursor motion events would also be sent to update the cursor location.
This depended on the behavior of the compositor, it failed for Sway
but worked for Gnome-shell & River.
Resolve by making use of the drop events cursor coordinates.
Backend initialization needs to be delayed until after the OpenGL context
is created. This worked fine in foreground mode because the OpenGL context
already exists for the window at the point GPU_backend_init_once was called,
but not for background mode.
Create the backend just in time in GPU_context_create as before, and
automatically free it when the last context id discarded. But check if any
GPU backend is supported before creating the OpenGL context.
Ref D15463, D15465
This causes an assert with libepoxy, but was wrong already regardless.
Refactor logic to work as follows:
* GPU_exit() deletes backend resources
* Destroy UI GPU resources with the context active
* Call GPU_backend_exit() after deleting the context
Ref D15291
Differential Revision: https://developer.blender.org/D15465
When rendering with headless builds, show an error instead of crashing.
Previously GPU_backend_init was called indirectly from
DRW_opengl_context_create, a new function is now called from the window
manager (GPU_backend_init_once), so it's possible to check if the GPU
has a back-end.
This also disables the `bgl` Python module when building WITH_HEADLESS.
Reviewed By: fclem
Ref D15463
The goal of this change is to fix an increasing bottleneck of the event
queue handling when there is an operator bound to a key press event and
is taking longer to finish than a key-repeat speed on the system.
Practical example of when it happens is the marker tracking operator in
a single-frame track mode. Quite often artists will hold down Alt-arrow
to track a segment of footage which seems trivial to track. The issue
arises when the Alt-arrow is released: prior to this change it is was
possible that more frames will be tracked. It also seems that redraws
are less smooth.
It is a bit hard to make easily shareable computer-independent test
case. Instead, a synthetic case can be reproduced by adding a 50 ms
sleep in the `text_move_exec()`. In such synthetic case open a long
text in the text editor and hold left/right arrow button to navigate
the cursor. The observed behavior is that seemingly redraws happen
less and less often and cursor travels longer and longer distances
between redraws. The cursor will also keep moving after the buttons
has been released.
The proposed solution is to ignore sequential key-press events from
being added to the event queue. This seems to be the least intrusive
and the most safe approach:
- If the operator is fast enough there will be no multiple press events
in the queue in both prior and after of this change.
- If the operator is slow enough, clicking the button multiple times
(i.e. clicking arrow button 3 times in a heavy shot will change the
scene frame by exactly 3 frames because no events are ignored in
this case).
- Only do it for key press events, keeping mouse and tabled behavior
unchanged which is crucial for the paint mode.
Note that this is a bit different from the key repeat tracking and
filtering which is already implemented for keymaps as here we only want
to avoid the event queue build-up and do want to ignore all repeat
events. In other words: we do want to handle as many key presses as the
operator performance allows it without clogging anything.
A possible extension to this change could be a key press counter, so
that instead of ignoring the event we merge it into the last event in
the queue, incrementing some counter. This way if some operator really
needs to know exact number of key repeats it can still access it.
Differential Revision: https://developer.blender.org/D15444
We would first invoke the dragging, and then set the drag data (like the
ID or the dragged modifier), so the `wmDropBox.on_drag_start()` handler
wouldn't be able to access this. This broke dragging some IDs from the
Outliner, noticed in D15333.
It's now possible to first create/request drag data, extend it, and then
invoke the actual dragging. The normal function to start dragging
returns `void` now instead of `wmDrag *`, so the drag data can't easily
be modified after starting anymore.
- Remove references to `ISTEXTINPUT` as any keyboard event with it's
utf8_buf set can be handled as text input.
- Update references to the key repeat flag.
