Improved Icons #115536

New Issue

Harley Acheson · 2023-11-28T18:06:42+01:00

Harley Acheson commented

2023-11-28 18:06:42 +01:00

Current Limitations

Our current icons have a number of limitations and complications. We have multiple kinds of icons to address different uses, each with a complicated process to create and maintain them that quite often gets out of sync. Each type also has technical limitations, and/or sizing limitations, and/or performance problems.

Our main UI icons are designed on a 14x14 grid in a single SVG source document that is exported into multiple bitmaps in two sizes, 16x16 and 32x32. This looks... okay, but sizes in between these two are suboptimal in that they are roughly scaled by the shader. Sizes above 32x32 are needed for large and/or high-dpi displays, but are blurry. These are generally made in shades of grey, but we have a process where these can be recolored as the theme text color, and we can also force some to be certain colors.

Tool icons are designed in a blend file and are exported as vector shapes with positions on 1/256ths and with hardcoded feature colors. These vector shapes are rasterized to bitmaps at twice the needed size and are then reduced for antialiasing. These must be rasterized because we don't have a way to draw these vectors and shapes on the GPU in a way that preserves the shading of overlapping translucent shapes while also being antialiased. But the rasterizing is a slow process. We only cache one size of these at a time, which means the cache will not be used if we have multiple sizes needed simultaneously, like when 3D Views are on multiple monitors that differ in scale. This results in them being constantly rasterized.

We also have some supplemental images and icons because we have some need for them at larger sizes. "alert_icons" are 5 icons made on a 256x256 grid that we use in dialogs. "prv_icons" are 7 icons, also at 256x256, that we use during thumbnail view in File Browser. We also have a "blender_logo" at 1024x256. These types visually degrade if shown larger than their design, but they also look suboptimal below their designs because of rough scaling.

Attempts to Address

I had hoped that we could at least add a third size level to our regular icons, in 64x64. But that attempt - #112261 - is a failure. Although it looked good, this results in more RAM usage when not always needed. It also has unacceptable startup performance if icon shadowing (used in the light theme) is turned on.

Solution: Icons as Text

Our text output system is very efficient at showing vector shapes at any size. Rasterized glyphs are cached in multiple sizes simultaneously and are handled efficiently. If we can put the icons in a font file we can show each at any size at any time, with the added benefit of being able to mix text and icons in the same simple output string.

Although there have been "icon fonts" for many years now, these have all contained icons comprised of strokes - designed within the early limitations of font design. This type of font has not suited our needs because they do not support color or overlapping shapes of varying opacity.

But this changes with the OpenType SVG standard. This is basically a font file that contains an SVG file inside each glyph, and therefore supports most features of SVG. This could support every type of icon mentioned above, in any size, with color support, and each glyph is optimized for that particular requested size.

FreeType added support for OT-SVG a couple releases ago. But it isn't quite as straightforward as you might wish. It added hooks that are called at various places in the rendering process where you can optionally read the SVG content and render it out to a bitmap surface using an SVG library that you supply.

So far this seems to be testing out okay, but it is early yet. One complication is that this requires supporting full RGBA bitmaps from FreeType, not just our current single-channel bitmaps. This can be added in #115452.

Assuming this works, this could streamline our processes greatly. Our current SVG source files would be broken up into multiples, one per image, in a single folder. A python script could be created that creates a single font file from these source SVG files, with each icon assigned into a private portion of the Unicode range.

There is an attractive possibility that would be impossible to ignore, so should be built into the planning. Our code would be handed some SVG source, which we then pass off to an SVG rasterizer, but there is no reason why we can't alter that SVG source first. So we can alter the specified colors in the same way that CSS can alter colors in an SVG if done correctly. Icons could have some highlight color that changes with the theme (like the features in the vertex, edge, face selection mode icons). Or tool icons could have all the current hard-coded "green" portions shown as blue or any other color. Assuming the SVG is made in a way that names the colors in a consistent way.

One odd thing to consider is the sizing of icons relative to text. It might seem logical to just have a typical square icon take up the entirety of the em-square. So you can make one that is 64x64 by specifying a font size of 64. However this results in quite small icons when you have a simple string that mixes text and icons together. Although such a string could be broken into multiples with differing sizes, it might be best to start with the simple case and make that look good. We might want our current balance of 11 point text with 14 pixel-high icons.

Implementation Notes

There are surprisingly few implementations as described above. Most existing OT-SVG fonts I have examined have PNG images inside the SVG glyph documents, instead of vectors. Online utilities that seem create these types of fonts quite often make ".svg" files instead - SVG documents that are treated as a font, rather than an OpenType-SVG font.

One surprise, that is not a surprise in hindsight, is that the SVG docs are considered alternatives to the regular glyphs, not a replacement. The intention is that there are regular B&W regular stroke glyphs and then there are also SVG documents that can supersede them. And this is seen in every font I have examined, which makes sense since they want their font to show something if the fancy versions can't be shown. We, course, would only have the fancy versions.

Building the font using SVG sources using python appears possible, but is a surprisingly complex process. And there are few examples that are remotely similar to what we need. Closest is probably noto-emoji-svg, which needs a 483-line py file to first create the regular BW font file, and then a 290-line py file to add the SVG images to it. In our case that first process would probably need to add placeholders (like a notdef tofu square) for each of our icons. As mentioned, this is not something anything else does, and there might be complications like needing that BW versions to mirror the size and extent of the SVG , so might need to be the SVG bounding box. At least the noto-emoji-svg project illustrates creating notdef by drawing it out, rather than using an imported glyph.

Proof of Concept

I have a proof of concept PR which mostly works (and also crashes) which using NanoSVG in the FreeType callbacks. Following is glyphs from the OpenType-SVG version of Noto Emoji:

### Current Limitations Our current icons have a number of limitations and complications. We have multiple kinds of icons to address different uses, each with a complicated process to create and maintain them that quite often gets out of sync. Each type also has technical limitations, and/or sizing limitations, and/or performance problems. Our main UI icons are designed on a 14x14 grid in a single SVG source document that is exported into multiple bitmaps in two sizes, 16x16 and 32x32. This looks... okay, but sizes in between these two are suboptimal in that they are roughly scaled by the shader. Sizes above 32x32 are needed for large and/or high-dpi displays, but are blurry. These are generally made in shades of grey, but we have a process where these can be recolored as the theme text color, and we can also force some to be certain colors. Tool icons are designed in a blend file and are exported as vector shapes with positions on 1/256ths and with hardcoded feature colors. These vector shapes are rasterized to bitmaps at twice the needed size and are then reduced for antialiasing. These must be rasterized because we don't have a way to draw these vectors and shapes on the GPU in a way that preserves the shading of overlapping translucent shapes while also being antialiased. But the rasterizing is a slow process. We only cache one size of these at a time, which means the cache will not be used if we have multiple sizes needed simultaneously, like when 3D Views are on multiple monitors that differ in scale. This results in them being constantly rasterized. We also have some supplemental images and icons because we have some need for them at larger sizes. "alert_icons" are 5 icons made on a 256x256 grid that we use in dialogs. "prv_icons" are 7 icons, also at 256x256, that we use during thumbnail view in File Browser. We also have a "blender_logo" at 1024x256. These types visually degrade if shown larger than their design, but they also look suboptimal below their designs because of rough scaling. ### Attempts to Address I had hoped that we could at least add a third size level to our regular icons, in 64x64. But that attempt - #112261 - is a failure. Although it looked good, this results in more RAM usage when not always needed. It also has unacceptable startup performance if icon shadowing (used in the light theme) is turned on. ### Solution: Icons as Text Our text output system is very efficient at showing vector shapes at any size. Rasterized glyphs are cached in multiple sizes simultaneously and are handled efficiently. If we can put the icons in a font file we can show each at any size at any time, with the added benefit of being able to mix text and icons in the same simple output string. Although there have been "icon fonts" for many years now, these have all contained icons comprised of strokes - designed within the early limitations of font design. This type of font has not suited our needs because they do not support color or overlapping shapes of varying opacity. But this changes with the OpenType SVG standard. This is basically a font file that contains an SVG file inside each glyph, and therefore supports most features of SVG. This could support every type of icon mentioned above, in any size, with color support, and each glyph is optimized for that particular requested size. FreeType added support for OT-SVG a couple releases ago. But it isn't quite as straightforward as you might wish. It added hooks that are called at various places in the rendering process where you can optionally read the SVG content and render it out to a bitmap surface using an SVG library that you supply. So far this seems to be testing out okay, but it is early yet. One complication is that this requires supporting full RGBA bitmaps from FreeType, not just our current single-channel bitmaps. This can be added in #115452. Assuming this works, this could streamline our processes greatly. Our current SVG source files would be broken up into multiples, one per image, in a single folder. A python script could be created that creates a single font file from these source SVG files, with each icon assigned into a private portion of the Unicode range. There is an attractive possibility that would be impossible to ignore, so should be built into the planning. Our code would be handed some SVG source, which we then pass off to an SVG rasterizer, but there is no reason why we can't alter that SVG source first. So we can alter the specified colors in the same way that CSS can alter colors in an SVG if done correctly. Icons could have some highlight color that changes with the theme (like the features in the vertex, edge, face selection mode icons). Or tool icons could have all the current hard-coded "green" portions shown as blue or any other color. Assuming the SVG is made in a way that names the colors in a consistent way. One odd thing to consider is the sizing of icons relative to text. It might seem logical to just have a typical square icon take up the entirety of the em-square. So you can make one that is 64x64 by specifying a font size of 64. However this results in quite small icons when you have a simple string that mixes text and icons together. Although such a string could be broken into multiples with differing sizes, it might be best to start with the simple case and make that look good. We might want our current balance of 11 point text with 14 pixel-high icons. ### Implementation Notes There are surprisingly few implementations as described above. Most existing OT-SVG fonts I have examined have PNG images inside the SVG glyph documents, instead of vectors. Online utilities that seem create these types of fonts quite often make ".svg" files instead - SVG documents that are treated as a font, rather than an OpenType-SVG font. One surprise, that is not a surprise in hindsight, is that the SVG docs are considered alternatives to the regular glyphs, not a replacement. The intention is that there are regular B&W regular stroke glyphs and then there are also SVG documents that can supersede them. And this is seen in every font I have examined, which makes sense since they want their font to show something if the fancy versions can't be shown. We, course, would only have the fancy versions. Building the font using SVG sources using python appears possible, but is a surprisingly complex process. And there are few examples that are remotely similar to what we need. Closest is probably [noto-emoji-svg](https://github.com/adobe-fonts/noto-emoji-svg), which needs a 483-line py file to first create the regular BW font file, and then a 290-line py file to add the SVG images to it. In our case that first process would probably need to add placeholders (like a notdef tofu square) for each of our icons. As mentioned, this is not something anything else does, and there might be complications like needing that BW versions to mirror the size and extent of the SVG , so might need to be the SVG bounding box. At least the noto-emoji-svg project illustrates creating notdef by drawing it out, rather than using an imported glyph. ### Proof of Concept I have a [proof of concept PR](https://projects.blender.org/blender/blender/pulls/115812) which mostly works (and also crashes) which using NanoSVG in the FreeType callbacks. Following is glyphs from the OpenType-SVG version of Noto Emoji: ![image](/attachments/dfde7782-1d80-4b56-9355-2b2c44ace870)

image.png

47 KiB

image.png

35 KiB

❤️ 9

Harley Acheson added the

Type

Design

label 2023-11-28 18:06:42 +01:00

Harley Acheson added this to the User Interface project 2023-11-28 18:06:44 +01:00

RedMser commented

2023-11-28 18:43:31 +01:00

This sounds great! Especially the more advanced possibilities, like changing the colors that are used within icons.

each icon assigned into a private portion of the Unicode range.

when you have a simple string that mixes text and icons together

So this change would mean that it'll be possible to render icons inline with text, without having to use something like layout.label(icon='...')? Or is the icon font not going to be added into the regular font fallback stack?

This sounds great! Especially the more advanced possibilities, like changing the colors that are used within icons. > each icon assigned into a private portion of the Unicode range. > when you have a simple string that mixes text and icons together So this change would mean that it'll be possible to render icons inline with text, without having to use something like `layout.label(icon='...')`? Or is the icon font not going to be added into the regular font fallback stack?

Harley Acheson commented

2023-11-28 20:57:20 +01:00

So this change would mean that it'll be possible to render icons inline with text, without having to use something like layout.label(icon='...')? Or is the icon font not going to be added into the regular font fallback stack?

Yes, it would be in the stack so you could just mix text and icons in the same string. With the only complication that these icons would have quite high Unicode values. I could probably make some utility to help with that. Or an updated "Icon viewer" add-on could lets us just copy and paste those values around.

> So this change would mean that it'll be possible to render icons inline with text, without having to use something like `layout.label(icon='...')`? Or is the icon font not going to be added into the regular font fallback stack? Yes, it would be in the stack so you could just mix text and icons in the same string. With the only complication that these icons would have quite high Unicode values. I could probably make some utility to help with that. Or an updated "Icon viewer" add-on could lets us just copy and paste those values around.

👍 5

Harley Acheson referenced this issue

2024-03-01 00:06:42 +01:00

Roadmap #118940

Sign in to join this conversation.