Blender Behind the Scenes

After having analyzed Blender’s context in the first essay and its codebase architecture in the second, we take a look at the quality of the codebase in this third essay. Because Blender is already over 25 years old, and because of the complicated nature of the functionality it aims to deliver, we initially expect Blender to have a large amount of technical debt — the degree of inaccessibility, or, the number of “deficiencies in internal quality that make it harder than it would ideally be to modify and extend the system further.”¹ In order to ensure a certain code quality, Blender maintains some rules, such as “no code gets in trunk without documentation” (meaning that contributors have to document new functionality in the Blender Documentation)², no new warnings are allowed, and code style has to remain consistent within files ³. Numerous other guidelines can be found at ⁴.

Blender’s release cycle is heavily tuned towards bug fixing ⁵. Blender aims to release an update every three months, but the actual development of an update takes longer and overlaps with other updates, as shown in the figure below. Each update consists of five phases — Bcon1 through Bcon5 — and starts on the master branch. Bcon1 takes nine weeks and has developers focus mainly on new features and big changes. Bcon2 is four weeks, and is focused on improving, optimizing and stabilizing new and existing features, and only smaller changes and features are made here. From Bcon3 onward, the release gets its own branch, on which four weeks are spent on bug fixing⁶ in Bcon3, one week is spent preparing the update in Bcon4, and the update is released in Bcon5. Also at the start of an update’s Bcon3 phase, the succeeding update’s Bcon1 phase starts. Developers spent 1-2 on update 1’s Bcon3 phase, and the rest to update 2’s Bcon1 phase. Therefore, approximately 60% - 70% of the time is spent on code improvement.

Automated testing

Blender’s testing pipeline is “a work in progress and isn’t anywhere near full coverage”⁷, and contributors are invited to add unit tests and increase coverage. Test coverage as a percentage of the codebase is not tracked, as the developers feel that there are “not enough tests to really be worth it at the moment. Focus is more on adding tests for things that we know are likely to break and lead to real bugs, for which such percentages are not always a good measure”⁸. They have some basic tests for the Python code (mainly UI and add-ons), and they use the Google Test unit testing library for the C/C++ (the majority of Blender’s codebase). Tests for both these parts are called with CMake’s CTest. Google Test needs to be enabled at build-time through a CMake build option (WITH_GTESTS), and creates testing executables which it then runs.⁹ Blender publishes nightly unstable builds¹⁰, and these are tested with the aforementioned test suites. However, since Blender lacks the resources to test and build every commit¹¹, we can’t speak of Blender using a continuous integration or CI/CD approach.

The Python tests use Python’s own unittest module. Python’s tests can be run from the command line if Blender and Python are installed.¹² The list of Python tests is shown below.

Apart from these, there are exactly one hundred tests for the C/C++ code. 31 of these test libmv (the Blender-maintained multiview reconstruction library used for Blender’s motion tracking¹³), 28 tests cover the Cycles rendering engine, 33 cover the various functions and types of the Blender Library (BLI), and the rest is meant for mesh operators and modifiers, and other I/O-functions, tools, and small internal libraries. Tests for the EEVEE and Blender Workbench rendering engines are disabled by default, because different GPUs yield different test results.¹⁴ All tests are shown below.

Let’s take a look at one GTest test and one Python test. The file BLI_path_util_test.cc (test #112) tests Blender’s path utilities. The #include "BLI_path_util.h" indicates that this file tests path_util.c. Besides procedures for setting up and tearing down, the test file contains 24 unit tests, each of which tests one function path_util.c. Each such unit test, then, tests approximately 5-20 configurations, depending on the function under scrutiny. Ten unit tests investigate the BLI_path_name_at_index function, seven unit tests investigate BLI_path_join, and the functions BLI_split_dirfile, BLI_path_frame_strip, BLI_path_extension_check, BLI_path_frame_check_chars, BLI_path_frame_range, BLI_path_frame_get, and BLI_path_extension all get one unit test. However, path_util.c defines 51 functions, meaning upward of 40 functions aren’t tested. The Python test file bl_pyapi_mathutils.py (test #46) tests the source/blender/python/mathutils component. It defines a “test case” (which is essentially the same as a unit test¹⁵) for the following datatypes: Matrix, Vector, Quaternion, and KDTree; and for the tessellate_polygon(polyline) function. However, this component also contains many other functions and object, like EulerObject, Color, all sorts of intersaction/collision tests, geometrical interpolation functions, and noise generators. Therefore, also this component is not fully covered.

Coding hotspots

Blender is a very large system. Files or directories where many commits or line changes are occuring are also called “coding hotspots”. These coding hotspots can give one insight into which direction the system is developing. The latest stable version of Blender is version 2.82a, released on March 12th, 2020. Since then Blender has entered the Bcon2 stage of the 2.83 release cycle. The following table shows the number of commits, line insertions and deletions since March 12th for the top level directories.

Directory	Commits	Insertions	Deletions
source	290	135308	98723
release	52	279216	276144
intern	43	19900	13317
build_files	13	1167	865
tests	9	3712	378

At first glance it seems like the source and release directory seem to be the largest hotspots of coding activity, due to the number of commits and line changes respectively. In case of the release directory, this is due to the addition of a single file that contains more than 270 thousand lines. Further investigations in the source directory yields the following table.

Directory	Commits
source	290
source/blender	286
source/blender/editors	119
source/blender/blenkernel	93
source/blender/makesrna	53
source/blender/draw	48
source/blender/windowmanager	27
source/blender/makesdna	26
source/blender/blenloader	21
source/blender/depsgraph	17
source/blender/modifier	16
source/blender/gpu	13
source/blender/blenlin	12

The editors and blenkernel directories contain the most changes. blenkernel commits are mostly located in the intern subdirectory which contains all the source files. The editors contains more interesting subdirectories as each subdirectory located there is a feature. These distribution of code activity can be seen in the next table.

Directory	Commits
source/blender/editors/gpencil	27
source/blender/editors/editors	25
source/blender/editors/sculpt_paint	20
source/blender/editors/include	20
source/blender/editors/transform	17
source/blender/editors/object	16
source/blender/editors/animation	15
source/blender/editors/space_view3d	12
source/blender/editors/screen	11

As can be seen from the table, the gpencil and sculpt_paint directories are quite high on the list, meaning that there’s still a lot to work going on for these features. These features also showed up in prior release notes and were highlighted in a (video)[https://www.youtube.com/watch?v=EfF2wDXalgU] posted on Blender’s YouTube channel.

Roadmap activity

Blender does not have a global roadmap per release cycle due to their size. Instead, each module owner maintains a list of tasks. These lists contain tasks that are to be completed in a single release cycle as well as tasks that may span multiple release cycles. It is therefore rather difficult to keep track of what their goals are for a specific version. They do keep track of the changes that have been made in their (release notes)[https://wiki.blender.org/wiki/Reference/Release_Notes/2.83]. Blender has posted a roadmap for their release planning¹⁶ as well as big projects that they would like to tackle before in the year of 2020 ¹⁷. Blender 2.83 seems to revolve mainly around adding small sized features as well as bug fixes. Larger objectives, such as their upcoming Everything Nodes and Asset Manager projects, are projected to be included in later releases.

Technical debt

Searching through the forums of Blender at ¹⁸ and the Blender chat ¹⁹, there is little talk of technical debt amongst contributors. It is doubtful that many of them are actively worried about this during discussions, as Blender themselves hold code quality days ²⁰ on each first Friday of each month. These days are fully dedicated on improving the Blender code quality. Any contributer who is interested is allowed to participate in the code quality days. The coordination is done online through the Blender chat. They usually work on:

• adding comments to explain code, giving overviews.
• renaming obscure functions and variables.
• split up big files into more organized smaller ones.
• Uupdate the wiki documentation.

A glance at Blender’s development website²¹ suggests that they share each task done during code quality days as separate tasks so that other contributors can chime in. In these tasks, it is possible to see discussions of testing new ideas, and code quality discussions between contributers. From these, we can conclude that Blender uses the code quality days in order to help reduce the technical debt and improve the code quality of Blender, rather than doing this per feature being worked on. This iterating through the code on a scheduled basis seems like a more organized way of bringing clarity to the project. Consequently, the code becomes easier to understand for new developers and saves time in implementing new features.

Automated code quality analysis

Static analysis can be used to generate an assessment of code quality. Popular projects for this purpose are SonarQube ²² and SIG ²³. We have set up SonarQube to do static analysis on the Blender project, as we only have little results from SIG’s Sigrid, apart from the dependency graph. However, we did hear that — in the subset of components we submitted — there are 1401 cyclic dependencies, 380 indirect cyclic dependencies, and 45 bypassing layers.

The code of Blender mainly consists of C/C++ code. Unfortunately, the (free) community edition of SonarQube does not offer support for these languages. However, the UI and some tooling have been written in Python which is supported. Therefore, SonarQube could be run on Python and some markup languages within the Blender source code.

The analysis consists of 727 files and 101,000 lines of code, of which 98% is Python code. SonarQube lists 84 bugs, but many of these do not affect how Blender runs as a program. For example, there is a 10 years old HTML file that describes Blender’s file format. This file contains many bugs and code smells: the ‘Verdana’ font is used which may not be present on all computers, and <th> (table header) elements don’t have an id associated with them so that screen readers may not announce the columns of the table. Furthermore, a dozen bugs of severity “Blocker” — stating that bpy is not defined — are listed. This is however not a bug, but rather a side-effect of Python being set up in a custom way within Blender itself.

A lot of potential code improvements can be found, however, such as empty code blocks that can be removed, commented-out code, and functions that have a lower case and an upper case variant with the same name.

SonarQube also reports a section for technical debt. Even though over 3,000 instances of code smell are found within the Python codebase, this amount is still low considering the size of the project. The overall technical debt is estimated at 69 days of engineering work, which mostly pertains to the UI code. All in all, SonarQube considers the maintainability of the Python part of Blender’s source code good, as the technical debt ratio is lower than 5%.

Conclusion

In conclusion, Blender adheres to a very strict and streamlined development process. They spent a significant time on code improvement and bug fixes. The small amount of SIG’s Sigrid analysis results tell us that Blender violates a nontrivial number of good practices, while SonarQube tell us that Blender does not have as much technical debt as one would expect from a 25-year-old project. Especially given Blender’s sheer complexity, we think it’s code quality is surprisingly good and well-maintained, which also makes it easier for new developers to helpt contribute to Blender.