The conversion from int to float is not supported natively
so it ends up happening beforehand on the CPU or as a
step before the vertex buffer can be used. It's better to just
upload floats in the first place.
Related to:
- 1e1ac2bb9b
- 617858e453
Pull Request: https://projects.blender.org/blender/blender/pulls/138855
This converts the public `uiItemO` function to an object oriented
API (`uiLayout::op`).
Also this rearranges `idname` paramether, since this the only one
required, and to make format similar to `uiItemFullO`
Note: One of the benefits of moving from a public function to class
method is to reduce API usage difference between C++ and Python. In
Python this method is called `UILayout::operator`, however `operator`
is a reserved keyword in C++.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/138776
This converts the public `uiItemR` function to an object oriented
API (`uiLayout::prop`), matching the python API.
This reduces the difference between the C++ API with the python version,
its also helps while converting code from python to C++ code (or vice-versa),
making it almost seamless.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/138617
This converts the public `uiItemL` function to an object oriented
API (`uiLayout::label`), matching the python API.
This reduces the difference between the C++ API with the python version,
its also helps while converting code from python to C++ code (or vice-versa),
making it almost seamless.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/138608
This converts the public `uiLayoutAbsolute ` and `uiLayoutAbsoluteBlock`
functions to an object oriented API (an `uiLayout::absolute` and
`uiLayout::absolute_block` respectively), following recent changes.
`uiLayout::absolute` now returns an uiLayout reference instead of a
pointer. New calls to this method should use references too.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/138546
This patch adds a new `BLI_mutex.hh` header which adds `blender::Mutex` as alias
for either `tbb::mutex` or `std::mutex` depending on whether TBB is enabled.
Description copied from the patch:
```
/**
* blender::Mutex should be used as the default mutex in Blender. It implements a subset of the API
* of std::mutex but has overall better guaranteed properties. It can be used with RAII helpers
* like std::lock_guard. However, it is not compatible with e.g. std::condition_variable. So one
* still has to use std::mutex for that case.
*
* The mutex provided by TBB has these properties:
* - It's as fast as a spin-lock in the non-contended case, i.e. when no other thread is trying to
* lock the mutex at the same time.
* - In the contended case, it spins a couple of times but then blocks to avoid draining system
* resources by spinning for a long time.
* - It's only 1 byte large, compared to e.g. 40 bytes when using the std::mutex of GCC. This makes
* it more feasible to have many smaller mutexes which can improve scalability of algorithms
* compared to using fewer larger mutexes. Also it just reduces "memory slop" across Blender.
* - It is *not* a fair mutex, i.e. it's not guaranteed that a thread will ever be able to lock the
* mutex when there are always more than one threads that try to lock it. In the majority of
* cases, using a fair mutex just causes extra overhead without any benefit. std::mutex is not
* guaranteed to be fair either.
*/
```
The performance benchmark suggests that the impact is negilible in almost
all cases. The only benchmarks that show interesting behavior are the once
testing foreach zones in Geometry Nodes. These tests are explicitly testing
overhead, which I still have to reduce over time. So it's not unexpected that
changing the mutex has an impact there. What's interesting is that on macos the
performance improves a lot while on linux it gets worse. Since that overhead
should eventually be removed almost entirely, I don't really consider that
blocking.
Links:
* Documentation of different mutex flavors in TBB:
https://www.intel.com/content/www/us/en/docs/onetbb/developer-guide-api-reference/2021-12/mutex-flavors.html
* Older implementation of a similar mutex by me:
https://archive.blender.org/developer/differential/0016/0016711/index.html
* Interesting read regarding how a mutex can be this small:
https://webkit.org/blog/6161/locking-in-webkit/
Pull Request: https://projects.blender.org/blender/blender/pulls/138370
This converts the public `uiLayoutSplit` function to an object oriented
API (`uiLayout::split`), matching the python API.
This reduces the difference between the C++ API with the python version,
its also helps while converting code from python to C++ code (or vice-versa),
making it almost seamless.
`uiLayout::split` now returns an `uiLayout` reference instead of a pointer.
New calls to this method should use references too.
Pull Request: https://projects.blender.org/blender/blender/pulls/138361
* Remove `DEG_get_evaluated_object` in favor of `DEG_get_evaluated`.
* Remove `DEG_is_original_object` in favor of `DEG_is_original`.
* Remove `DEG_is_evaluated_object` in favor of `DEG_is_evaluated`.
Pull Request: https://projects.blender.org/blender/blender/pulls/138317
- ImBuf reference counting: turn that into just an atomic integer
- Cachefile safety: turn into a mutex, since work under the spinlock
was quite heavy (hashtable creation, other memory allocations)
- Movie clip editor: turn into a mutex, since work under the spinlock
was very heavy (reading files from disk, etc.)
- Mesh intersect: remove the previously commented out spinlock path;
replace BLI mutex with C++ mutex for shorter code
Pull Request: https://projects.blender.org/blender/blender/pulls/137989
This converts the public `uiLayoutColumn` function to an object oriented
API (`uiLayout::column`), matching the python API.
This reduces the difference between the C++ API with the python version,
its also helps while converting code from python to C++ code (or vice-versa),
making it almost seamless.
`uiLayout::column` now returns an `uiLayout` reference instead of a pointer.
New calls to this method should use references too.
Pull Request: https://projects.blender.org/blender/blender/pulls/138034
This converts the public `uiLayoutRow` function to an object oriented
API (`uiLayout::row`), matching the python API.
This reduces the difference between the C++ API with the python version,
its also helps while converting code from python to C++ code (or vice-versa),
making it almost seamless.
`uiLayout::row` now returns an `uiLayout` reference instead of a pointer.
New calls to this method should use references too.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/137979
It's safer to pass a type so that it can be checked if delete should be
used instead. Also changes a few void pointer casts to const_cast so that
if the data becomes typed it's an error.
Pull Request: https://projects.blender.org/blender/blender/pulls/137404
This fixes most "One Definition Rule" violations inside blender proper
resulting from duplicate structures of the same name. The fixes were
made similar to that of !135491. See also #120444 for how this has come
up in the past.
These were found by using the following compile options:
-flto=4 -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing
Note: There are still various ODR issues remaining that require
more / different fixes than what was done here.
Pull Request: https://projects.blender.org/blender/blender/pulls/136371
The goal is to be able to switch away from OpenMP by default.
In order to achieve this a new parallel_for() function is added,
which follows the same declaration as the one from TBB. For now
the simplest formulation is used where range is provided by start
and last indices (the last one is excluded from the range).
The side effect is that Libmv now expects the threading limits
to be imposed by the default thread area (or have an explicit
thread area with the limit in the caller). In a way this is
similar to other external libraries.
Pull Request: https://projects.blender.org/blender/blender/pulls/136834
Use enum types for event modifier and types,
`wmEventModifierFlag` & `wmEventType` respectively.
This helps with readability and avoids unintended mixing with other
types. To quiet GCC's `-Wswitch` warnings many `default` cases needed
to be added to switch statements on event types.
Ref !136759
Part of incoming refactors in interface layout c++ code, this enables
forward declaring this enum type. Enum is renamed as `EmbossType` and
moved to `blender::ui` namespace. No user visible changes expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/136725
Callbacks: exec invoke & modal now use a typed enum wmOperatorStatus.
This helps avoid mistakes returning incompatible booleans or other
values which don't make sense for operators to return.
It also makes it more obvious functions in the WM API are intended
to be used to calculate return values for operator callbacks.
Operator enums have been moved into DNA_windowmanager_enums.h
so this can be used in other headers without loading other includes
indirectly.
No functional changes expected.
Ref !136227
The general idea is to keep the 'old', C-style MEM_callocN signature, and slowly
replace most of its usages with the new, C++-style type-safer template version.
* `MEM_cnew<T>` allocation version is renamed to `MEM_callocN<T>`.
* `MEM_cnew_array<T>` allocation version is renamed to `MEM_calloc_arrayN<T>`.
* `MEM_cnew<T>` duplicate version is renamed to `MEM_dupallocN<T>`.
Similar templates type-safe version of `MEM_mallocN` will be added soon
as well.
Following discussions in !134452.
NOTE: For now static type checking in `MEM_callocN` and related are slightly
different for Windows MSVC. This compiler seems to consider structs using the
`DNA_DEFINE_CXX_METHODS` macro as non-trivial (likely because their default
copy constructors are deleted). So using checks on trivially
constructible/destructible instead on this compiler/system.
Pull Request: https://projects.blender.org/blender/blender/pulls/134771
Move the code dealing with converting float3 to GPU normals
out of the vertex format header into a separate header. Use a
proper C++ namespace and remove duplication by only using
the more recently added C++ templated conversions.
Most of the diff comes from the removal of the indirect includes
from GPU_vertex_format.hh. A lot of files ended up mistakenly
depending on that.
Pull Request: https://projects.blender.org/blender/blender/pulls/134873
And replace nullptr arguments for tooltips in UI button
creation functions with std::nullopt. Though the distinction
between "no tooltip" and "empty tooltip" doesn't seem to exist,
it seems safer to keep the distinction since it existed with null before.
When there was an empty (no keyframes) track in the motion tracker's
dopesheet, Blender would crash when running the Frame All operator.
The issue was that the code computing the frame range was trying to
access non-existant data on the empty track, leading to a null pointer
dereference.
This fixes the issue by guarding that code with a nullptr check.
Pull Request: https://projects.blender.org/blender/blender/pulls/133371
Make it have similar display style and placement as current frame
indicators used elsewhere (timeline, animation etc.), i.e.
time_scrub_ui.cc draw_current_frame:
- The text label is centered on the frame (instead of left aligned),
- Background box uses rounded corners,
- Background box uses padding that scales with overall UI scale,
- Text color uses TH_HEADER_TEXT_HI which makes it more readable
This partially addresses issue #124287 (better text legibility, and
due to label being centered it is less clipped when on the right
side). But fully solving the issue would probably have to be done
across the board for all current frame indicators, with some design
work.
Screenshots in the PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/132911
When using clangd or running clang-tidy on headers there are
currently many errors. These are noisy in IDEs, make auto fixes
impossible, and break features like code completion, refactoring
and navigation.
This makes source/blender headers work by themselves, which is
generally the goal anyway. But #includes and forward declarations
were often incomplete.
* Add #includes and forward declarations
* Add IWYU pragma: export in a few places
* Remove some unused #includes (but there are many more)
* Tweak ShaderCreateInfo macros to work better with clangd
Some types of headers still have errors, these could be fixed or
worked around with more investigation. Mostly preprocessor
template headers like NOD_static_types.h.
Note that that disabling WITH_UNITY_BUILD is required for clangd to
work properly, otherwise compile_commands.json does not contain
the information for the relevant source files.
For more details see the developer docs:
https://developer.blender.org/docs/handbook/tooling/clangd/
Pull Request: https://projects.blender.org/blender/blender/pulls/132608
This caused build errors on the docs builder, I can't seem to reproduce
locally, so revert for now and have another look at some point in the
future.
Sadly as these changes usually go, this took 5c515e26bb and
2f0fc7fc9f with it as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/132559
Not entirely straightforward, some manual edits were done since when
this library was created, some of the work was already done.
- Remove any bf_imbuf_movie paths from INC
- Add a dependency though LIB when missing
- Add public dependency to bf_imbuf in bf_imbuf_movie since it uses the
imbuf headers in its public headers.
- Fix namespace not to have underscores
context: https://devtalk.blender.org/t/cmake-cleanup/30260
Pull Request: https://projects.blender.org/blender/blender/pulls/132407
- All movie related public headers now have MOV_ prefix instead of
IMB_movie_.
- All movie related public functions now have MOV_ prefix as well,
instead of IMB_movie_ or IMB_anim_.
- IMB_anim.hh -> MOV_read.hh (also ImBufAnim -> MovieReader), and
various utility functions not related to playback were split off
into MOV_util.hh.
- Other function name tweaks for clarity, e.g. IMB_suffix_anim
-> MOV_set_multiview_suffix and so on.
- All except one usages of MOV_get_fps (nee IMB_anim_get_fps) were
ultimately just converting returned value into a float. So make
MOV_get_fps just return that directly. For the (exactly just one)
place that needs numerator and denominator, have
MOV_get_fps_num_denom.
- Code comments on the public header functions.
- Removed never-used code paths inside movie timecode proxy building
file.
It might be easier to review each commit separately.
Pull Request: https://projects.blender.org/blender/blender/pulls/132145
Previously, code related to reading/writing movie files via ffmpeg was
scattered around: some under blenkernel, some directly in generic
imbuf headers, some under intern/ffmpeg. Some of the files were named
with not exactly clear names. Some parts not directly related to movies
were including ffmpeg headers directly (rna_scene.cc).
What is in this PR:
Movie and ffmpeg related code is now under imbuf/movie:
- IMB_anim.hh: movie reading, proxy querying, various utility functions.
- IMB_movie_enums.hh: simple enum definitions,
- IMB_movie_write.hh: movie writing functions.
- intern: actual implementation and private headers.
- ffmpeg_compat.h: various ffmpeg version difference handling
utilities,
- ffmpeg_swscale.hh/cc: scaling and format conversion utilities
for ffmpeg libswscale,
- ffmpeg_util.hh/cc: misc utilities related to ffmpeg,
- movie_proxy_indexer.hh/cc: proxies and timecode indexing for movies,
- movie_read.hh/cc: decoding of movies into images,
- movie_write.cc: encoding of images into movies.
- tests: basic ffmpeg library unit tests that previously
lived under intern/ffmpeg.
Interface changes (at C++ level, no Python API changes):
- Mostly just movie related functions that were BKE_ previously, are now IMB_.
- I did one large-ish change though, and that is to remove bMovieHandle
struct that had pointers to several functions. Now that is
IMB_movie_write_begin, IMB_movie_write_append, IMB_movie_write_end
functions using a single opaque struct handle. As a result, usages
of that in pipeline.cc and render_opengl.cc have changed.
Pull Request: https://projects.blender.org/blender/blender/pulls/132074
- Gives O(1) access to string length in more cases
- Convenient string manipulation functions
- Clarify difference between "no string" and "empty string"
- Avoid the need for raw pointers in the API
- Shows which API string arguments are optional
Pull Request: https://projects.blender.org/blender/blender/pulls/131473
#126806 stopped the drawing of horizontal scrollbars when the areas
were very short. However this still left their hit areas still
active. This PR properly removes the scrollbar in this situation by
also changing the v2d.scroll flags.
Pull Request: https://projects.blender.org/blender/blender/pulls/130764
