Not sure why multiple pools were created: the pool should be able to
handle two sets of tasks.
Perhaps non-measurable improvement in terms of performance but this
change simplifies code a bit.
Was accidental regression in rBed9b21098dd27bf9364397357f89b4c2648f40c2
Remove the input slider's PROP_FACTOR subtype in favor of the default to
align with other IOR sliders. This provides much better control when
dragging the value with the mouse.
Differential Revision: https://developer.blender.org/D15477
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.
Due to the ordering of the checks, assert and async were not highlighted
in the editor, even though they were in the list of keywords.
Differential Revision: http://developer.blender.org/D15483
Although e.g. in the dopesheet there is no specific concept of
active action, displaying panels requires singling out one action
reference. It is more efficient and clearer to implement this
natively in the context rather than using selected_visible_actions[0].
- In the Action Editor the action is taken from the header.
- In the Dope Sheet the first selected action is chosen, because
there is no concept of an active channel or keyframe.
- In the Graph Editor the action associated with the active curve
is used, which should also be associated with the active vertex.
This case may be different from selected_visible_actions[0].
Differential Revision: https://developer.blender.org/D15412
openSubdiv_init() would detect available evaluators before any OpenGL context
exists, causing a crash with libepoxy. This test however is redundant as we
already check the requirements on the Blender side through the GPU API.
To simplify things, completely remove the device detection in the opensubdiv
module and reduce the evaluators to just CPU and GPU. The plan here is to move
to the GPU module abstraction over OpenGL/Metal/Vulkan and so all these
different backends no longer make sense.
This also removes the user preference for OpenSubdiv compute device, which was
not used for the new GPU subdivision implementation.
Ref D15291
Differential Revision: https://developer.blender.org/D15470
The stroke code now supports raycasting the original mesh.
This fixes anchored mode not working for negative brushes,
which might move the mesh out of the initial mouse cursor
position.
The scene spacing code was failing to
check if a raycast failed, which can happen
when sculpting the edges of objects in negative
mode.
Note I removed what I suspect was a hack put
in to fix this, spacing was clamped
to 0.001 scene units.
Scene spacing mode is actually quite broken,
so it will be fixed in a series of phases.
Fix for {T99039}.
The problem was that `AUD_mixdown` and `AUD_mixdown_per_channel` were returning pointers to freed memory.
Two key changes are made:
1. The return value of those functions now simply return a bool as to whether the operation succeeded, instead of an optional error string pointer.
2. The error string buffer is now passed into the function to be filled in case an error occurs. In this way, the onus of memory ownership is unamibiguously on the caller.
Differential Revision: https://developer.blender.org/D15260
Instead of removing the `bgl` module, set all it's functions to stubs
so importing `bgl` or any of it's members doesn't raise an error.
This avoids problems for scripts that import bgl but don't call it's
functions when running in background mode.
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
An increased number of vertices is not a stopper for the surface
deform modifier anymore. It might still be useful to expose the
message in the UI, but printing error message to the console on
every modifier evaluation makes real errors to become almost
invisible.
Differential Revision: https://developer.blender.org/D15468
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
This includes:
- new modifier names
It mostly uses `N_` because the strings are actually translated elsewhere.
The goal is simply to export them to .po files.
Most of the new translations were reported in T43295#1105335.
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D15418
The outliner would tagg all existing local IDs (for remap from linked
reference data to newly created overrides) when creating a new override.
This would become critical issue in case there is several existing
copies of the same override hierarchy (leading to several hierarchies
using the same override).
Further more, BKE override creation code would not systematically
properly remapp linked usages to new overrides one whithin the affected
override hierarchy, leading to potential undesired remaining usages of
linked data.
This is useful when using an armature as a camera rig, to avoid creating and
targetting an empty object.
Differential Revision: https://developer.blender.org/D7012
* Snap border to pixels just outside the drawn border, to more easily select
specific pixels by drawing a border inside them.
* Support cropped border renders.
Fix unreported: Resize with Constrain To Bounds will now limit one shared scale
value for both U and V instead of calculating separate scale values for each.
To fix T98061, the individual origins (transdata->center) is now used when
that mode is active.
See also: 0e9367fc29
Differential Revision: https://developer.blender.org/D15420
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
For bit counts that were exact multiple of block size, the macro was
computing one block too much.
Reviewed By: Campbell Barton, Bastien Montagne
Differential Revision: https://developer.blender.org/D15454
In preparation for a larger change (D14162), some BLI_bitmap
functionality that could be submitted separately:
- Ability to declare a fixed size bitmap by-value, without extra
memory allocation: BLI_BITMAP_DECLARE
- Function to find the index of lowest unset bit:
BLI_bitmap_find_first_unset
- Test coverage of the above.
Reviewed By: Campbell Barton, Bastien Montagne
Differential Revision: https://developer.blender.org/D15454
Use const pointers to ImageSaveOptions and ImageFormatData for API
parameters where appropriate.
Differential Revision: https://developer.blender.org/D15400
It was smart enough to check if the buffer had the right
size but neglected to cast to a 64 bit value so it
overflowed.
Differential Revision: https://developer.blender.org/D15457
Reviewed By: brecht
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.
