[Bf-blender-cvs] [f78219c9a8b] master: Cleanup: spelling in comments
Campbell Barton
noreply at git.blender.org
Tue Sep 13 10:03:54 CEST 2022
Commit: f78219c9a8b17afd0222920bb3afb992132cbb11
Author: Campbell Barton
Date: Tue Sep 13 18:00:44 2022 +1000
Branches: master
https://developer.blender.org/rBf78219c9a8b17afd0222920bb3afb992132cbb11
Cleanup: spelling in comments
===================================================================
M source/blender/functions/FN_lazy_function.hh
M source/blender/functions/FN_lazy_function_execute.hh
M source/blender/functions/intern/lazy_function_graph_executor.cc
M source/blender/imbuf/intern/cineon/logImageCore.c
M source/blender/imbuf/intern/dds/FlipDXT.cpp
M source/blender/nodes/NOD_geometry_nodes_log.hh
===================================================================
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,
diff --git a/source/blender/imbuf/intern/cineon/logImageCore.c b/source/blender/imbuf/intern/cineon/logImageCore.c
index 69ec3c4bee8..8188d0d04b9 100644
--- a/source/blender/imbuf/intern/cineon/logImageCore.c
+++ b/source/blender/imbuf/intern/cineon/logImageCore.c
@@ -428,7 +428,7 @@ int logImageGetDataRGBA(LogImageFile *logImage, float *data, int dataIsLinearRGB
LogImageElement mergedElement;
/* Determine the depth of the picture and if there's a separate alpha element.
- * If the element is supported, load it into an uints array. */
+ * If the element is supported, load it into an `uint` array. */
memset(&elementData, 0, 8 * sizeof(float *));
hasAlpha = 0;
diff --git a/source/blender/imbuf/intern/dds/FlipDXT.cpp b/source/blender/imbuf/intern/dds/FlipDXT.cpp
index 682cf394d08..3d2b7e51a46 100644
--- a/source/blender/imbuf/intern/dds/FlipDXT.cpp
+++ b/source/blender/imbuf/intern/dds/FlipDXT.cpp
@@ -104,7 +104,7 @@ static void FlipDXT5BlockFull(uint8_t *block)
* bits = bits_0 + 256 * (bits_1 + 256 * (bits_2 + 256 * (bits_3 +
* 256 * (bits_4 + 256 * bits_5))))
*
- * bits is a 48-bit uinteger, from which a three-bit control code
+ * bits is a 48-bit unsigned-integer, from which a three-bit control code
* is extracted for a texel at location (x,y) in the block using:
*
* code(x,y) = bits[3*(4*y+x)+1..3*(4*y+x)+0]
diff --git a/source/blender/nodes/NOD_geometry_nodes_log.hh b/source/blender/nodes/NOD_geometry_nodes_log.hh
index f48d38ecbbf..dd4868b6ba0 100644
--- a/source/blender/nodes/NOD_geometry_nodes_log.hh
+++ b/source/blender/nodes/NOD_geometry_nodes_log.hh
@@ -20,7 +20,7 @@
* resources.
* - Log (#GeoTreeLog, #GeoNodeLog): Those are used when accessing logged data in UI code. They
* contain and cache preprocessed data produced during logging. The log combines data from all
- * threadlocal loggers to provide simple access. Importantly, the (preprocessed) log is only
+ * thread-local loggers to provide simple access. Importantly, the (preprocessed) log is only
* created when it is actually used by UI code.
*/
@@ -66,7 +66,7 @@ enum class NamedAttributeUsage {
ENUM_OPERATORS(NamedAttributeUsage, NamedAttributeUsage::Remove);
/**
- * Values of different types are logged differently. This is necesary because some types are so
+ * Values of different types are logged differently. This is necessary because some types are so
* simple that we can log them entirely (e.g. `int`), while we don't want to log all intermediate
* geometries in their entirety.
*
@@ -97,7 +97,7 @@ class GenericValueLog : public ValueLog {
/**
* Fields are not logged entirely, because they might contain arbitrarily large data (e.g.
- * geometries that are sampled). Instead, only the data needed for ui features is logged.
+ * geometries that are sampled). Instead, only the data needed for UI features is logged.
*/
class FieldInfoLog : public ValueLog {
public:
@@ -116,7 +116,7 @@ struct GeometryAttributeInfo {
/**
* Geometries are not logged entirely, because that would result in a lot of time and memory
- * overhead. Instead, only the data needed for ui features is logged.
+ * overhead. Instead, only the data needed for UI features is logged.
*/
class GeometryInfoLog : public ValueLog {
public:
@@ -308,7 +308,7 @@ class GeoModifierLog {
Map<ComputeContextHash, destruct_ptr<GeoTreeLogger>> tree_logger_by_context;
};
- /** Container for all threadlocal data. */
+ /** Container for all thread-local data. */
threading::EnumerableThreadSpecific<LocalData> data_per_thread_;
/**
* A #GeoTreeLog for every compute context. Those are created lazily when requested by UI code.
@@ -320,7 +320,7 @@ class GeoModifierLog {
~GeoModifierLog();
/**
- * Get a threadlocal logger for the current node tree.
+ * Get a thread-local logger for the current node tree.
*/
GeoTreeLogger &get_local_tree_logger(const ComputeContext &compute_context);
More information about the Bf-blender-cvs
mailing list