With the popularity of dark themes, and the fact that our default theme
is dark, make the initial background color (before the program fully
loads) a darker shade of grey. {0.25f, 0.25f, 0.25f} versus current
{0.55f, 0.55f, 0.55f}. Also set Windows class background brush to the
same color to remove a potential flash.
Pull Request: https://projects.blender.org/blender/blender/pulls/115968
The intent of `ghost_event_proc_timestamp_warning` is to give a console
warning when an event time is outside of an expected 5 second window
around the last time. However if an event happens within the first 5
seconds we get an overflow in a calculation and we get warnings for
normal times within the range.
Pull Request: https://projects.blender.org/blender/blender/pulls/116164
Link/append code sets the scene pointer to `null` when the active
scene is a linked one, to avoid attempt to instantiate linked data
(objects or collections) into a linked scene, which is forbidden.
However, code was still calling some functions expecting a valid scene
pointer, leading to crash.
It is unclear when exactly this issue was introduced code wise. From a
user perspective, it seems to have been revealed between 3.6 and 4.0
release (bisect points at 00a36cbf24, which does not seem to be
directly related...).
In any case, the fix is trivial and safe, so should we do another 4.0
bugfix release, this commit should be backported.
There are operators in Blender that allow the user to import multiple
files at the same time, however this functionality is only implemented
when importing with blender's file browser, drag and drop files only
takes first selected file.
The patch adds support for drag and drop multiple files.
Notes:
* The files are filtered according to the extension of the first
selected file.
* Not all operators that import files support importing multiple files,
so they will still import one.
* Changes must be made to allow importers to read all file paths.
This will be used in upcoming drag & drop import.
Pull Request: https://projects.blender.org/blender/blender/pulls/107230
Report suspicious time-stamps as they could cause bugs which are
difficult to troubleshoot.
Currently the time-stamps are only used for double-click detection but
we may want to use them in the future, so ensure they're valid.
Print an error when two events are handled in the last second and the
current event has a time-stamp 5 seconds before or after the current
time.
This is a smaller rewrite/refactor of the VSE copy paste code to use the file copy buffer logic that is used in other places of Blender.
This makes Blender able to copy paste between Blender processes.
It can also paste successfully after closing and reopening Blender.
Other than that, the functionally should remain the exact same as the current copy paste operator with one exception: Scene strips does not retain their scene pointer when pasting into the same file.
This is to make it consistent with how it was before when copy pasting between .blend files.
(The scene data for the scene strips were never copied in when doing that)
Logic for pulling in or linking scenes into new or current files are purposely left for later when a proper proposal of how this would work in a nice fashion is done.
Now the strip data gets copied either fully or partially besides for scene strips. There only the script data gets copied and not the scene data.
If there is a audio/video data block of the same name as in the paste data, it will be reused to reduce potential duplication of data.
Pull Request: https://projects.blender.org/blender/blender/pulls/114703
`wmDragActiveDropState` contains a `bContextStore` unique pointer, so
when constructing/destructing an object of this type `BKE_context.hh`
had to be included. It wouldn't be obvious why this include is necessary
in some cases. And the pointer is otherwise managed internally in the
source file, so the need for this include shouldn't bleed into other
files.
Make sure the unique pointer construction/destruction happens in the
translation unit of the source file that otherwise also manages it.
Avoids include in #107230.
Texture usage flag `GPU_TEXTURE_USAGE_MIP_SWIZZLE_VIEW`
was originally implemented and used too conservatively for many
cases in which the underlying API flags were not required.
Renaming to `GPU_TEXTURE_USAGE_FORMAT_VIEW` to reflect
the only essential use case for when a texture view is initialized with
a different texture format to the source texture. Texture views can
still be created without this flag when mip range or base level is
adjusted,
This flag is still required by stencil views and internally by the Metal
backend for certain feature support such as SRGB render toggling.
Patch also includes some small changes to the Metal backend to
adapt to this new compatibility and correctly capture all texture view
use-cases.
Related to #115269
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/115300
Address regression in [0] which allowed wmKeyMapItem::properties to
remain set when a valid wmKeyMapItem::ptr can't be created because the
wmOperatorType isn't available (temporarily in the case of reloading).
Resolve by freeing wmKeyMapItem::properties when the `ptr` isn't set.
Also add null pointer check not to assume wmKeyMapItem::properties
implies an allocated wmKeyMapItem::ptr. Something which is already
accounted for everywhere else.
[0]: 08e5f94a70
Also add null pointer check not to assume wmKeyMapItem::properties
implies an allocated wmKeyMapItem::ptr. Something which is already
accounted for everywhere else.
Avoid awkward kludges with IMB_init/exit & IMB_ffmpeg_init calls.
The animation player was responsible for calling IMB_exit, not IMB_init,
this complicated drag & drop which needed to re-internalize IMB before
returning.
Delay initializing IMB since none of the other argument handlers
depend on it, make wm_main_playanim_intern responsible for calling
both initialization & exit calls for IMB.
Also expand code comments for ARG_PASS_SETTINGS.
This was fixed by [0] however that fix didn't account for IMB
sometimes freeing GPU resources created by color management
(resolved by [1] which effectively reverted [0]).
Resolve by re-initializing IMB in the case of drag & drop.
[0]: 51467b0611
[1]: 05c56603a9
This was initially added a long time ago[1] to help with certain exit
behavior while running under a debugger. However, this shouldn't be
necessary any longer.
More importantly, tests have started to use the `--debug` option[2].
Somehow the bots are fine, but anyone running the tests locally on
Windows will experience what looks like a hang; unless they press a key
to allow the tests to continue.
[1] 1cc19c6993
[2] The `blendfile_versioning` test
Pull Request: https://projects.blender.org/blender/blender/pulls/114605
Standalone animation player has inconsistent GPU context activation
paradigm compared with standard rendering paths. The Metal backend
utilises the context activation step to refresh target window swapchains
from within the GHOST module.
This PR adds activation and deactivation calls, and also aims to clean up
GPU_render_begin/end setup to ensure all paths are covered.
Also resolves a bug upon shutdown wherein GPU resources which may
be tied to a GPU context are released during IMB_exit(), which is called
after GPU context destruction.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/114573
Root of the issue was that a1d7ec7139 (from !110109, new comptibility
handling) missed to update code of `handle_subversion_warning`, file
version numbers should be checked here now, not the minversion ones.
On top of that, this report has been changed to a `RPT_WARNING` instead
of a `RPT_ERROR`, and reports 'print level' for file reading was set to
`WARNING` level way too late to have any effect in existing code...
The last good commit was 8474716abb.
After this commits from main were pushed to blender-v4.0-release. These are
being reverted.
Commits a4880576dc from to b26f176d1a that happend afterwards were meant for
4.0, and their contents is preserved.
`WM_draw_region_free()` should manage region-draw data, and not change
region state. This should be done by normal region state management
functions. Especially for a flag like `ARegion::visible` which is just
the cached result of the region's visibility evaluation, not the proper
way to actualy manage the region visibility.
