diff options
Diffstat (limited to 'source/blender/functions')
-rw-r--r-- | source/blender/functions/FN_lazy_function.hh | 8 | ||||
-rw-r--r-- | source/blender/functions/FN_lazy_function_execute.hh | 2 | ||||
-rw-r--r-- | source/blender/functions/intern/lazy_function_graph_executor.cc | 14 |
3 files changed, 12 insertions, 12 deletions
diff --git a/source/blender/functions/FN_lazy_function.hh b/source/blender/functions/FN_lazy_function.hh index 8dceb9ed993..59a3a90b0b0 100644 --- a/source/blender/functions/FN_lazy_function.hh +++ b/source/blender/functions/FN_lazy_function.hh @@ -6,12 +6,12 @@ * \ingroup fn * * A `LazyFunction` encapsulates a computation which has inputs, outputs and potentially side - * effects. Most importantly, a `LazyFunction` supports lazyness in its inputs and outputs: + * effects. Most importantly, a `LazyFunction` supports laziness in its inputs and outputs: * - Only outputs that are actually used have to be computed. * - Inputs can be requested lazily based on which outputs are used or what side effects the * function has. * - * A lazy-function that uses lazyness may be executed more than once. The most common example is + * A lazy-function that uses laziness may be executed more than once. The most common example is * the geometry nodes switch node. Depending on a condition input, it decides which one of the * other inputs is actually used. From the perspective of the switch node, its execution works as * follows: @@ -27,7 +27,7 @@ * executed, it advances its state until all required outputs are ready. * * The lazy-function interface is designed to support composition of many such functions into a new - * lazy-functions, all while keeping the lazyness working. For example, in geometry nodes a switch + * lazy-functions, all while keeping the laziness working. For example, in geometry nodes a switch * node in a node group should still be able to decide whether a node in the parent group will be * executed or not. This is essential to avoid doing unnecessary work. * @@ -129,7 +129,7 @@ class Params { /** * Call this after the output value is initialized. After this is called, the value must not be - * touched anymore. It may be moved or destructed immediatly. + * touched anymore. It may be moved or destructed immediately. */ void output_set(int index); diff --git a/source/blender/functions/FN_lazy_function_execute.hh b/source/blender/functions/FN_lazy_function_execute.hh index 4213f5ca5f9..a59d363a9d5 100644 --- a/source/blender/functions/FN_lazy_function_execute.hh +++ b/source/blender/functions/FN_lazy_function_execute.hh @@ -97,7 +97,7 @@ inline void execute_lazy_function_eagerly_impl( /** * In some cases (mainly for tests), the set of inputs and outputs for a lazy-function is known at * compile time and one just wants to compute the outputs based on the inputs, without any - * lazyness. + * laziness. * * This function does exactly that. It takes all inputs in a tuple and writes the outputs to points * provided in a second tuple. Since all inputs have to be provided, the lazy-function has to diff --git a/source/blender/functions/intern/lazy_function_graph_executor.cc b/source/blender/functions/intern/lazy_function_graph_executor.cc index eca29121889..176509bd687 100644 --- a/source/blender/functions/intern/lazy_function_graph_executor.cc +++ b/source/blender/functions/intern/lazy_function_graph_executor.cc @@ -1,7 +1,7 @@ /* SPDX-License-Identifier: GPL-2.0-or-later */ /** - * This file implements the evaluation of a lazy-function graph. It's main objectices are: + * This file implements the evaluation of a lazy-function graph. It's main objectives are: * - Only compute values that are actually used. * - Allow spreading the work over an arbitrary number of CPU cores. * @@ -78,7 +78,7 @@ struct InputState { /** * Value of this input socket. By default, the value is empty. When other nodes are done * computing their outputs, the computed values will be forwarded to linked input sockets. The - * value will thenlive here until it is found that it is not needed anymore. + * value will then live here until it is found that it is not needed anymore. * * If #was_ready_for_execution is true, access does not require holding the node lock. */ @@ -532,10 +532,10 @@ class Executor { BLI_assert(locked_node.node.is_function()); switch (locked_node.node_state.schedule_state) { case NodeScheduleState::NotScheduled: { - /* Don't add the node to the task pool immeditately, because the task pool might start - * executing it immediatly (when Blender is started with a single thread). That would often - * result in a deadlock, because we are still holding the mutex of the current node. - * Also see comments in #LockedNode. */ + /* Don't add the node to the task pool immediately, because the task pool might start + * executing it immediately (when Blender is started with a single thread). + * That would often result in a deadlock, because we are still holding the mutex of the + * current node. Also see comments in #LockedNode. */ locked_node.node_state.schedule_state = NodeScheduleState::Scheduled; locked_node.delayed_scheduled_nodes.append( &static_cast<const FunctionNode &>(locked_node.node)); @@ -1057,7 +1057,7 @@ class GraphExecutorLFParams final : public Params { /** * Actually execute the node. * - * Making this `inline` results in a simpler backtrace in release builds. + * Making this `inline` results in a simpler back-trace in release builds. */ inline void Executor::execute_node(const FunctionNode &node, NodeState &node_state, |