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
This PR has very slight corrections to text cursor placement in input
widgets. The most important is a check for the situation where the
right edge of the current character can be greater than the left edge
of the next character. This can happen for some thin characters before
a space. Otherwise the code assumes RTL direction and gives an
incorrect placement. This also slightly tightens the position when at
the start of string, just after a space, or at end of the string.
Pull Request: https://projects.blender.org/blender/blender/pulls/127662
For the times we need to obtain the bitmap of an SVG icon, send these
through the new theme coloring callback if they are multi-color. This
removes some code duplication by adding a new function that gets an
imBuf from SVG Icon. This allows, for "About" logo, Dialog icons, and
file system icons the optional ability to use a single SVG source file
that works as both monochrome (themed by text color) or multicolor with
internal parts themed.
Pull Request: https://projects.blender.org/blender/blender/pulls/126215
Allow color SVG icons to have their fill colors modified by theme
colors using a callback. This is done just before rasterization so
only happens once per requested size, before these are cached for
reuse.
Pull Request: https://projects.blender.org/blender/blender/pulls/125146
When we draw SVG icons we have an optional argument that specifies to
treat it as multicolor. This PR allows doing the same thing when
requesting a bitmap from an icon. This is only currently done for
Dialog boxes and the About screen. The purpose of this isn't really
to allow multicolor dialog icons, but to get to the point where a
single SVG source file could be used as monochrome (changing the one
color with text color) or multi-color (changing internal colors with
themes) without needing multiple copies of the source file
Pull Request: https://projects.blender.org/blender/blender/pulls/126193
This PR corrects some mistakes in the conversion between RGBA bitmaps
created when rasterizing SVG icons and the monochrome coverage maps
when displaying these in a single color. This only occurs when we need
a bitmap from an icon for About screen and for dialogs. The bitmap
from NanoSVG is already premultiplied so don't do it again. When
converting from coverage map to RGBA use map value for all components
rather than FFF for colors. When converting to coverage map from RGBA
use perceptual grayscale level of color, not just alpha value.
Pull Request: https://projects.blender.org/blender/blender/pulls/126192
When we use icons that are multi-color, like for Tool icons, we'll
still need the ability to change their alpha at runtime. We do this
for hover effects, and as a theme setting.
Pull Request: https://projects.blender.org/blender/blender/pulls/126063
Slightly improved sub-pixel centering of icons within their bounds. This
also adds a minimum (negative) for the offsets for the future case of
icons that require a design that overflows the design grid. Not just
that that have non-square proportions but that also need to be maximum
height or width of the design grid. These should not center themselves
but be anchored at the specified location.
Pull Request: https://projects.blender.org/blender/blender/pulls/125844
This is visible in VSE text strip "box" and "outline" options at least.
For some fonts (mostly script/cursive type) BLF_boundbox function
was calculating horizontal bounds purely from pen position and
advance to the next character position. But the actual glyph can extend
beyond the advance distance.
Curiously, blf_font_boundbox_foreach_glyph (used by
blf_str_offset_from_cursor_position and blf_str_offset_to_glyph_bounds)
was already doing the correct thing and taking glyph horizontal bounds
into account.
Pull Request: https://projects.blender.org/blender/blender/pulls/125363
Size icons to subpixel precision to give slightly better results when used
with fractional resolution scales.
---
This change is very subtle. So you might have to trust me or get your reading glasses on...
Our icons are designed for small sizes. When the Blender resolution scale is set to exactly 1.0 then the icons are aligned perfectly to a 14x14 grid and features like lines are exactly one pixel wide. So these one-pixel wide lines are perfectly aligned to the pixel grid. Change the scale to 2.0x and they also align perfectly, just with lines that are two pixels wide.
But what happens at 1.25x scale? Now the icon is 17.5 pixels and lines in it are a pixel and a quarter wide . The best that can be is a solid pixel and one next to it that is quarter-opacity. But it can get worse than that as it could potentially touch three adjacent pixels.
Our old icon code took an icon bitmap that was rendered larger and scaled it into the desired size. Because this was done by the opengl shader, this scaling was done to subpixel size. So at 1.25 scale you got an icon that was 17.5 pixels.
The new icon code is truncating the sizes to integer before rendering. I thought this was best, but I was wrong.
The following image has three rows. The top is the old icon code, with UI scale from 1.0, 1.25, 1.5, 1.75, and 2.0. The second row is current code. The third is with this PR:
The first and last columns are identical, obviously because the design perfectly fits the pixel grid.
The left green area, at 1.25 scale, current code is forcing the design into an integer size, while (bottom) gives a more pleasing result as it is properly spread over 17.5 pixels.
The right green area is more interesting. With both the old code and new code, the 1.75 pixel wide line is spread over three pixels. The PR nicely spreads it over two pixels.
Hard to tell; Just squint. This is just very slightly more pleasing rendering of icons.
Pull Request: https://projects.blender.org/blender/blender/pulls/124436
Only when the user changes the UI font to one that does not have a
variable weight axis, update the text style weights to match the font's
design weight. So if changing to an old-school font that has a fixed
weight, for example bold, also update UI Text Style weights to match
so everything looks as designed and expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/124074
On rare occassions we need to turn an icon into a bitmap rather than
just draw it. For example, File Browser needs the bitmaps of the large
folder and file icons for use while dragging list items. This PR just
adds functions for this conversion from cached glyphs, and then uses
them to load the gSpecialFileImages "prv" icons so we no longer have
to include these in an embedded PNG file.
Pull Request: https://projects.blender.org/blender/blender/pulls/123749
Distribute our UI icons as separate SVG files in a folder in the
Blender installation. Rasterize each only when requested at the exact
size needed, and then saved in the text glyph cache for later uses.
Pull Request: https://projects.blender.org/blender/blender/pulls/121718
Add a separate function that calculates text selection box positioning
given a string's selection start and end offsets. Moves this to a
better place and allows to have more complex boxes in future when we
might have multi-line and/or multi-directional text input.
Pull Request: https://projects.blender.org/blender/blender/pulls/121448
With Aras's recent changes in #121383, our text shader now supports
outline shadows, which gives a result that has more contrast than can
be achieved with BLF_draw_default_shadowed. This removes that function.
Pull Request: https://projects.blender.org/blender/blender/pulls/121676
Overlay texts were previously drawn with two sets of shadows:
- 3px blur,
- 5px blur, slightly offset
But since the shadow color was always set to black, it was still
causing legibility issues when the text itself was dark (set
via theme for example).
This PR adds a new "outline" BLF text decoration, and uses that
for the overlays. And it picks text/outline color depending
on the "background" color of the view.
Details:
- Instead of "shadow level" integer where the only valid options
are 0, 3 or 5, have a FontShadowType enum.
- Add a new FontShadowType::Outline enum entry, that does a 1px
outline by doing a 3x3 dilation in the font shader.
- BLF_draw_default_shadowed is changed to do outline, instead of
drawing the shadow twice.
- In the font shader, instead of encoding shadow type in signs of
the glyph_size, pass that as a "flags" vertex attribute. Put
font texture channel count into the same flags, so that the
vertex size stays the same.
- Well actually, vertex size becomes smaller by 4 bytes, since turns
out glyph_mode vertex attribute was not used for anything at all.
Images in the PR.
Co-authored-by: Harley Acheson <harley.acheson@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/121383
BLF_buffer was trying to accept "how many colors channels in output
image?" argument and doing math with it, but in the lowest level code
was always writing out full 4 channels for each pixel.
All the call sites would ever call it with argument of 4 however, and
that is why no one noticed the issue.
Pull Request: https://projects.blender.org/blender/blender/pulls/121630
