Performance drops in node editor when rendering multiple special characters in socket names. #105891

New Issue

Closed

opened 2023-03-18 23:40:28 +01:00 by zorro-weaver · 2 comments

zorro-weaver commented

2023-03-18 23:40:28 +01:00

System Information
Operating system: Windows-10-10.0.19045-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 2070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 528.24

Blender Version
Broken: version: 3.4.0, branch: blender-v3.4-release, commit date: 2022-12-06 18:46, hash: rBa95bf1ac01be
Worked: (newest version of Blender that worked as expected)

Short description of error
I'd like to use special unicode icons to add some pizazz and visibility to my important nodegroup sockets. However, doing so has a massive performance hit in the node editor. It seems to only affec zooming, and only happens when you have more than one type of icon. The bug is present in all node editors.

Exact steps for others to reproduce the error

Open any node editor and create a nodegroup.
Inside the nodegroup, add a socket and rename it, adding an emoji or special unicode character.
Repeat step 2, using a different character.
Exit the nodegroup.
Attempt to zoom in or out. It will be drastically slower than usual. Other actions such as panning, moving nodes and adding nodes are not affected.

**System Information** Operating system: Windows-10-10.0.19045-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 2070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 528.24 **Blender Version** Broken: version: 3.4.0, branch: blender-v3.4-release, commit date: 2022-12-06 18:46, hash: `rBa95bf1ac01be` Worked: (newest version of Blender that worked as expected) **Short description of error** I'd like to use special unicode icons to add some pizazz and visibility to my important nodegroup sockets. However, doing so has a massive performance hit in the node editor. It seems to only affec zooming, and only happens when you have more than one type of icon. The bug is present in all node editors. **Exact steps for others to reproduce the error** 1. Open any node editor and create a nodegroup. 1. Inside the nodegroup, add a socket and rename it, adding an emoji or special unicode character. 1. Repeat step 2, using a different character. 1. Exit the nodegroup. 1. Attempt to zoom in or out. It will be drastically slower than usual. Other actions such as panning, moving nodes and adding nodes are not affected.

751 KiB

zorro-weaver added the

labels 2023-03-18 23:40:29 +01:00

Harley Acheson self-assigned this 2023-03-19 00:15:03 +01:00

Pratik Borhade added

Nodes & Physics

and removed

labels 2023-03-19 06:24:58 +01:00

Pratik Borhade commented

2023-03-19 06:25:09 +01:00

Member

I can confirm.

I can confirm.

Harley Acheson commented

2023-03-22 17:31:49 +01:00

Member

Thanks for this report. I think I can improve this performance a bit.

First a bit of a backgrounder.

You are now able to select from those emojis and lots of other new characters because we are no longer using a single font, but a "stack" of fonts. So when a character is not found in the main font we look in a list of alternative fonts. This is done in conjunction with a new caching scheme that also only loads fonts when they are needed, and can unload them when no longer needed.

In your example case you are using character "🙂" U+1F642 in the Unicode block "Emoticons" (U+1F600 - U+1F64F) in the Supplementary Multilingual Plane (U+10000 - U+1FFFF), and "🍔" U+1F354 in the block "Miscellaneous Symbols and Pictographs" (U+1F300 - U+1F5FF) also in the
Supplementary Multilingual Plane.

The reason you get a slowdown while zooming but not in regular usage is because we cache the rendered glyphs once we find them. So although we have to go through some work to look through other fonts to locate these characters we don't have to do this often.

However, when zooming we are (necessarily) having to re-render everything at a new size, which means we do have to look through our fonts to find them.

My first concern with this was that this lookup was causing us to go over our allocated maximum number of simultaneously loaded fonts. This wouldn't be a big problem, as the font cache is very good at temporarily unloading fonts, loading new ones, etc. But it would just be a bit slower than if it didn't have to do so. But this isn't the case here as during zooming there are no fonts unloaded or loaded.

The lookup of the glyphs does show a couple ways to improve though.

At this point of the code we are using our regular UI font, DejaVuSans.woff2, and needing some glyphs it does not have (Slightly Smiling Face and Hamburger). It goes through our fallback font stack but does not touch files that are unrelated to this Unicode range.

However it does load and test against our monospaced font, DejaVuSansMono.woff2. This font has "coverage bits" set that indicate that is has some glyphs in this range. However I can't see any reason to look in a monospaced font for a proportional use. The reverse would be fine though. I'll look into stopping this and possibly correcting its coverage bits.

It also tests against our large "Noto Sans CJK Regular.woff2" font, which is used for Chinese, Japanese, and Korean. That font also includes the coverage bits for these glyph ranges. I'll look into changing the coverage bits because I would rather we get these ranges from our specific fonts (Noto Emoji, Symbols, Symbols2).

This should have us hit those characters faster.

@zorro-weaver Thanks for this report. I *think* I can improve this performance a bit. First a bit of a backgrounder. You are now able to select from those emojis and lots of other new characters because we are no longer using a single font, but a "stack" of fonts. So when a character is not found in the main font we look in a list of alternative fonts. This is done in conjunction with a new caching scheme that also only loads fonts when they are needed, and can unload them when no longer needed. In your example case you are using character "🙂" U+1F642 in the Unicode block "Emoticons" (U+1F600 - U+1F64F) in the Supplementary Multilingual Plane (U+10000 - U+1FFFF), and "🍔" U+1F354 in the block "Miscellaneous Symbols and Pictographs" (U+1F300 - U+1F5FF) also in the Supplementary Multilingual Plane. The reason you get a slowdown while zooming but not in regular usage is because we cache the rendered glyphs once we find them. So although we have to go through some work to look through other fonts to locate these characters we don't have to do this often. However, when zooming we are (necessarily) having to re-render everything at a new size, which means we do have to look through our fonts to find them. My first concern with this was that this lookup was causing us to go over our allocated maximum number of simultaneously loaded fonts. This wouldn't be a big problem, as the font cache is very good at temporarily unloading fonts, loading new ones, etc. But it would just be a bit slower than if it didn't have to do so. But this isn't the case here as during zooming there are no fonts unloaded or loaded. The lookup of the glyphs does show a couple ways to improve though. At this point of the code we are using our regular UI font, DejaVuSans.woff2, and needing some glyphs it does not have (Slightly Smiling Face and Hamburger). It goes through our fallback font stack but does not touch files that are unrelated to this Unicode range. However it does load and test against our monospaced font, DejaVuSansMono.woff2. This font has "coverage bits" set that indicate that is has some glyphs in this range. However I can't see any reason to look in a monospaced font for a proportional use. The reverse would be fine though. I'll look into stopping this and possibly correcting its coverage bits. It also tests against our large "Noto Sans CJK Regular.woff2" font, which is used for Chinese, Japanese, and Korean. That font also includes the coverage bits for these glyph ranges. I'll look into changing the coverage bits because I would rather we get these ranges from our specific fonts (Noto Emoji, Symbols, Symbols2). This should have us hit those characters faster.

Harley Acheson referenced a pull request that will close this issue

2023-03-22 20:04:30 +01:00

Fix #105891: Faster Font Fallback Finding #106011

Harley Acheson referenced this issue from a commit

2023-03-24 19:55:38 +01:00

Fix #105891: Faster Font Fallback Finding

Harley Acheson closed this issue

2023-03-24 19:55:39 +01:00

Blender Bot added

and removed

labels 2023-03-24 19:55:40 +01:00

Sign in to join this conversation.

No Label

Animation & Rigging

Asset Browser Project Overview

Automated Testing

Blender Asset Bundle

Dependency Graph

Development Management

EEVEE & Viewport

Images & Movies

Motion Tracking

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Render Pipeline

Sculpt, Paint & Texture

Video Sequencer

Virtual Reality

Blender 2.8 Project

Milestone 1: Basic, Local Asset Browser

Good First Issue

Animation & Rigging

Development Management

EEVEE & Viewport

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Sculpt, Paint & Texture

Needs Info from Developers

Needs Information from User

No Milestone

No project

No Assignees

3 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#105891

No description provided.