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
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
