Briefly about this change:
- OpenColorIO C-API is removed.
- The information about color spaces in ImBuf module is removed.
It was stored in global ListBase in colormanagement.cc.
- Both OpenColorIO and fallback implementation supports GPU drawing.
- Fallback implementation supports white point, RGB curves, etc.
- Removed check for support of GPU drawing in IMB.
Historically it was implemented in a separate library with C-API, this
is because way back C++ code needed to stay in intern. This causes all
sort of overheads, and even calls that are strictly considered bad
level.
This change moves OpenColorIO integration into a module within imbuf,
next to movie, and next to IMB_colormanagement which is the main user
of it. This allows to avoid copy of color spaces, displays, views etc
in the ImBuf: they were used to help quickly querying information to
be shown on the interface. With this change it can be stored in the
same data structures as what is used by the OpenColorIO integration.
While it might not be fully avoiding duplication it is now less, and
there is no need in the user code to maintain the copies.
In a lot of cases this change also avoids allocations done per access
to the OpenColorIO. For example, it is not needed anymore to allocate
image descriptor in a heap.
The bigger user-visible change is that the fallback implementation now
supports GLSL drawing, with the whole list of supported features, such
as curve mapping and white point. This should help simplifying code
which relies on color space conversion on GPU: there is no need to
figure out fallback solution in such cases. The only case when drawing
will not work is when there is some actual bug, or driver issue, and
shader has failed to compile.
The change avoids having an opaque type for color space, and instead
uses forward declaration. It is a bit verbose on declaration, but helps
avoiding unsafe type-casts. There are ways to solve this in the future,
like having a header for forward declaration, or to flatten the name
space a bit.
There should be no user-level changes under normal operation.
When building without OpenColorIO or the configuration has a typo or
is missing a fuller set of color management tools is applies (such as the
white point correction).
Pull Request: https://projects.blender.org/blender/blender/pulls/138433
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 PR adds more line breaking opportunities when breaking file paths.
This adds ".-%?&". Some, like "." are moved to the subsequent line, to
keep period with the extension.
Pull Request: https://projects.blender.org/blender/blender/pulls/137972
This PR adds new typographical line breaking opportunities, characters
that break depending on what follows. For example comma if not followed
by a space or a number. Period if not followed by a space or another
period. Along with related non-Latin equivalents, like Greek question
mark, full width punctuation, Hebrew, Arabic, etc.
Pull Request: https://projects.blender.org/blender/blender/pulls/137934
For Text Objects make sure we don't render a glyph for tab or other
control characters. Return nothing for carriage return and line feed,
and treat the others as a space character.
Pull Request: https://projects.blender.org/blender/blender/pulls/137374
For tooltips, use typographical line breaking with hard limit for uses
of the regular font, path wrapping with hard limit for uses of the
monospaced font. Small correction to wrapping code so that hard limit
is not taken if there are optional breaking points.
Pull Request: https://projects.blender.org/blender/blender/pulls/136148
The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
MEM_[cm]allocN<T> templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use MEM_new (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
Pull Request: https://projects.blender.org/blender/blender/pulls/136126
The PR allows specifying the method of line breaking. Current functions
gain an optional argument that defaults to "Minimal" which breaks as it
does now, only on space and line feed. "Typographical" breaks on
different types of spaces, backslashes, underscore, forward slash if
not following a number, dashes if not following a space, Chinese,
Japanese, and Korean Ideograms, and Tibetan intersyllabic marks. "Path"
breaks on space, underscore, and per-platform path separators. There is
also a "HardLimit" flag that forces breaking at character boundary at
the wrapping limit.
Pull Request: https://projects.blender.org/blender/blender/pulls/135203
BLF tests for font file opening, display name, metrics, variable
weight changing, width, height, advances, etc. Also tests for current
minimal word wrapping.
Pull Request: https://projects.blender.org/blender/blender/pulls/135891
Add support for using BLF to draw into an ImBuf image buffer.
Once the imbuf context has been set, draw calls for that font_id will draw into the image.
This works by binding an imbuf to BLF which is then used as the target when drawing.
```
with blf.bind_imbuf(font_id, imbuf):
blf.draw_buffer(font_id, text)
```
See the example in the Python API documentation for reference.
The following BLF API's have been added to support a Python context manager.
- `BLF_buffer_state_push`.
- `BLF_buffer_state_pop`
- `BLF_buffer_state_free`
Ref !135772
With 4da5377e17 control characters are shown as space characters. But
word wrapping code will use the codepoint from the glyph if available,
which means a soft wrap on space instead of a hard wrap on line feed.
Just oversight, no need to use the glyph for that. In fact we always
want to deal with the character, not the visual representation of it.
Pull Request: https://projects.blender.org/blender/blender/pulls/135541
Prior versions of Blender showed control characters as spaces, but
since we recently made fallback optional they are no longer visible.
This is because with fallback we are guaranteed to return a glyph, but
without fallback the current font will not have entries for these. This
PR just shows them as spaces, just like before. But does not do so for
carriage return and line feed.
Pull Request: https://projects.blender.org/blender/blender/pulls/135484
Noticed while working on #134814 that `BLF_width_to_rstrlen()` would
give one character too much to put into the available space, resulting
in a visual overflow or clipped text when BLF clipping is enabled.
I think the issue was hidden by the code from 9c09998530, which would
remove further characters until the string actually fits. I'm proposing
to disable that code for now, hoping that this properly fixes the issue.
`BLF_width_to_rstrlen()`/`blf_font_width_to_rstrlen()` are supposed to
find the largest part from the end of a string that fits into a given
width. It would iterate the string from the back until a character
doesn't fit into the width anymore. However, it would return the
index of that character, the one that doesn't fit anymore, instead of
the last character known to fit.
Pull Request: https://projects.blender.org/blender/blender/pulls/135239
Our text wrapping code is written in a way that requires the Line Feed
character to be in our glyph cache. This is problematic as none of the
control characters will ever be there if not using fallback. With
fallback these glyphs could be a zero-width character from a symbol
font, or something with width if using a last resort font. So we'd have
to ignore the advance in the latter case. This came to a head recently
because we are turning off fallback in some circumstances. 12b1f8bd7a
removed the rendering of control characters so they are never in the
cache. That change requires this one, which does wrapping based on the
string's codepoint, not that of its glyph.
Pull Request: https://projects.blender.org/blender/blender/pulls/135196
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
with #133413 the intent was that VSE Text strips would not use the
fallback font stack if using a custom (non-default) font. However this
determination was done by comparing the font id. This was very weak as
the id can vary quite a bit within the first few fonts. This PR instead
adds a BLF function (BLF_is_builtin) that uses BLF_DEFAULT font flag
instead.
Pull Request: https://projects.blender.org/blender/blender/pulls/135014
Text characters in the CO Controls range, 0-31, are not meant to have
any displayable representation. For most Blender code this hasn't
mattered since we usually specifically exclude this range in text
processing. But for times when we don't we need to avoid rendering
glyphs in this range as some fonts contain blank (but not empty) items
here.
Pull Request: https://projects.blender.org/blender/blender/pulls/135013
If a sequencer text strip is using a custom font (not the default one)
then don't use the fallback font. This adds a new font flag to disable
the use of fallback.
Pull Request: https://projects.blender.org/blender/blender/pulls/133510
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
Previously, calling `clear()` on `Map`, `Set` or `VectorSet` would remove all
elements but did not free the already allocated capacity. This is fine in most
cases, but has very bad and non-obvious worst-case behavior as can be seen in
#131793. The issue is that having a huge hash table with only very few elements
is inefficient when having to iterate over it (e.g. when clearing).
There used to be a `clear_and_shrink()` method to avoid this worst-case
behavior. However, it's not obvious that this should be used to improve
performance.
This patch changes the behavior of `clear` to what `clear_and_shrink` did before
to avoid accidentally running in worst-case behavior. The old behavior is still
available with the name `clear_and_keep_capacity`. This is more efficient if
it's known that the hash-table is filled with approximately the same number of
elements or more again.
The main annoying aspect from an API perspective is that for `Vector`, the
default behavior of `clear` is and should stay to not free the memory. `Vector`
does not have the same worst-case behavior when there is a lot of unused
capacity (besides taking up memory), because the extra memory is never looked
at. `std::vector::clear` also does not free the memory, so that's the expected
behavior. While this patch introduces an inconsistency between `Vector` and
`Map/Set/VectorSet` with regards to freeing memory, it makes them more
consistent in that `clear` is the better default when reusing the data-structure
repeatedly.
I went over existing uses of `clear` to see if any of them should be changed to
`clear_and_keep_capacity`. None of them seemed to really benefit from that or
showed that it was impossible to get into the worst-case scenario. Therefore,
this patch slightly changes the behavior of these calls (only performance wise,
semantics are exactly the same).
Pull Request: https://projects.blender.org/blender/blender/pulls/131852
Currently when a character is requested that is not found in the
selected font we first look in other fonts that are already loaded that
include some of the requested Unicode range. If not found in any of
those we then look in unloaded fonts. But multiple fonts often have
overlapping coverage, so this means you can sometimes get a character
from different fonts depending on the order they are requested. Since
the design of that character could differ, this can lead to visual
changes. This PR changes the fallback search to do so in a consistent
order, not favoring loaded or unloaded. This does not lead to any
measurable performance changes in testing.
Pull Request: https://projects.blender.org/blender/blender/pulls/131812
When the user selects a font, only use characters from that font,
see code comments in BKE_vfontdata_char_from_freetypefont
for details.
Partially reverts [0] which changed behavior when VFont was
updated to use BLF.
Ref: !131821
[0]: 604ee2d036
When measuring text strings we consider both the advance and the glyph
bounding box. But monospaced text should only use the advance because
many fonts allow some mono characters to slightly overflow. This just
removes bounding box from the calculation of width for mono text.
Pull Request: https://projects.blender.org/blender/blender/pulls/131114
Prefetching happens on a background thread by design, and so it was not loading
any fonts and using the default monospace font.
Address this by making all font usage within VSE use "unique" BLF font objects,
and protecting concurrent access to them or their state within VSE itself:
- SeqFontMap structure to hold a mutex, file path -> font ID map (for file
based fonts), name -> font ID map (for datablock fonts).
- seq_load_font_file, seq_load_font_mem, seq_unload_font that use the above
instead of calling into BLF directly.
- Text effect rendering part guards with a mutex, so that font render state and
glyph cache does not get trashed.
- SeqFontMap is global instead of some Scene-specific runtime data (e.g.
scene->ed), because right now there's a hard max limit of total number of
fonts (64), and if each copy of the VSE data would start to load their own
unique fonts, that limit could get easily reached.
- BLF font loading/unloading code is now thread safe. The rest of BLF drawing
is still not!
If at some point in the future BLF font usage becomes thread safe, and font
drawing becomes "stateless", this whole machinery can be removed.
Pull Request: https://projects.blender.org/blender/blender/pulls/130542
Previously, alignment did exist, but it only changed whole text block
position in relation to a fixed point. This was later renamed to "Anchor".
Now it correctly aligns each line of text. Alignment works with newline
character and word wrapping.
Currently newline characters can't be entered directly, but this should
be resolved soon.
To keep existing anchoring feature, new DNA fields are added and
values from old alignment are copied there.
This PR is part of bigger change [1], and originally I expected to
implement this feature at later stage. But the design called for drawing
text character by character, which would mean, that I would have to
rewrite text alignment anyway.
To render the text, a struct is built, where position and width of each
character is stored. In addition, width of each line is stored. This allows
to implement proper text alignment feature, instead of existing
anchoring. Text is then drawn character by character in a loop.
There are some small differences in text rendering, since this is only
approximation of how BLF library draws glyphs, but it is very close.
For text bounbox, `BLF_boundbox()` is used on per line basis,
because some fonts do not use their full height and this information
is not available on VSE side.
[1] https://projects.blender.org/blender/blender/issues/126547
Pull Request: https://projects.blender.org/blender/blender/pulls/126660
