The execution time of blf.dimension is slow on Node Editor #104274

New Issue

nutti · 2023-02-01T06:53:46+01:00

nutti commented

2023-02-01 06:53:46 +01:00

System Information
Operating system: Windows 10
Graphics card: NVIDIA GeForce RTX 2060 SUPER

Blender Version
Broken: 3.5 alpha (Feb 1 2023, 345dded146)
Worked: 3.4 or before

Short description of error

This issue relates to https://developer.blender.org/T103210 as I reported before.
When we call Python API blf.dimension on Node Editor while zooming in/out , the execution time is much longer than other editors.
The cause of issue comes from the slow execution time of blf.dimension while zooming in/out.

Exact steps for others to reproduce the error

blf_dimension_slow_issue.blend

Open .blend file attached to this task.
Execute the script on Text Editor.
Move to Node editor
Zoom in/out by mouse wheel up/down
You will see that zooming is laggy because of the slow execution time of blf.dimension

**System Information** Operating system: Windows 10 Graphics card: NVIDIA GeForce RTX 2060 SUPER **Blender Version** Broken: 3.5 alpha (Feb 1 2023, 345dded146e5) Worked: 3.4 or before **Short description of error** This issue relates to https://developer.blender.org/T103210 as I reported before. When we call Python API `blf.dimension` on Node Editor while zooming in/out , the execution time is much longer than other editors. The cause of issue comes from the slow execution time of `blf.dimension` while zooming in/out. **Exact steps for others to reproduce the error** [blf_dimension_slow_issue.blend](https://archive.blender.org/developer/F14226149/blf_dimension_slow_issue.blend) 1. Open .blend file attached to this task. 2. Execute the script on Text Editor. 3. Move to Node editor 4. Zoom in/out by mouse wheel up/down 5. You will see that zooming is laggy because of the slow execution time of `blf.dimension`

nutti commented

2023-02-01 06:53:46 +01:00

Added subscriber: @nutti

Richard Antalik commented

2023-02-01 09:46:47 +01:00

Added subscribers: @Harley, @iss

Richard Antalik commented

2023-02-01 09:46:47 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Richard Antalik commented

2023-02-01 09:46:47 +01:00

I was able to reproduce lag with 1 zoom event, but I assume this casues issues when string changes? But will confirm, since repro case is same as in previous report.

Philipp Oeser commented

2023-02-02 10:59:51 +01:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2023-02-02 10:59:51 +01:00

@Harley : is this something you could look at?

Harley Acheson self-assigned this 2023-02-02 17:57:45 +01:00

Harley Acheson commented

2023-02-02 17:57:45 +01:00

Let me have this one for a bit, as I have been wanting to look into something that might be related. This one is a little different from #103210 (The execution time of blf.dimension is slow on Dope Sheet Editor) though...

When you zoom in/out in the Node Editor you see every intermediate step between where you started and where you end up. If it takes you half a second to zoom from a small size to a larger one you actually create 30 sizes in between.

Displaying text is very fast, but only because of caching. The rendering of each character (turning it into a little bitmap from curves) is quite slow, so we cache them for each size and style. We don't want you to be using memory to hold all those intermediate sizes when zooming so when you stop doing so we clear the caches. This means that immediately after you finish zooming we have to render again at the new size, but this is largely unnoticed because you aren't really doing anything at that time. But that can slow down your text measurement since those characters are not in the cache yet.

With #103210 (The execution time of blf.dimension is slow on Dope Sheet Editor) it was a matter of us clearing that cache unnecessarily. Zooming in Dope Sheet (and a few others) does not actually change the font size so there is no reason to clear that cache in that case, hence the solution here: {d11f3267cd93}

But zooming in the Node Editor(s) does change font size so the problem remains here.

Fairly certain that just clearing all glyph caches except for the last one (first in the list) would help you, be a performance improvement, and would have not negative effects that I can think of off the top of my head. But I'll need to make sure. And if I'm going to touch this it might be nice to get slightly fancier and keep the last one and any that match the current global (non-zoomed areas) size. Realistically I'd hope to look at this within the next couple of weeks with the goal to (hopefully) have an improvement for the 2.6 release.

Let me have this one for a bit, as I have been wanting to look into something that might be related. This one is a little different from #103210 (The execution time of blf.dimension is slow on Dope Sheet Editor) though... When you zoom in/out in the Node Editor you see every intermediate step between where you started and where you end up. If it takes you half a second to zoom from a small size to a larger one you actually create 30 sizes in between. Displaying text is very fast, but only because of caching. The rendering of each character (turning it into a little bitmap from curves) is quite slow, so we cache them for each size and style. We don't want you to be using memory to hold all those intermediate sizes when zooming so when you stop doing so we clear the caches. This means that immediately after you finish zooming we have to render again at the new size, but this is largely unnoticed because you aren't really doing anything at that time. But that can slow down your text measurement since those characters are not in the cache yet. With #103210 (The execution time of blf.dimension is slow on Dope Sheet Editor) it was a matter of us clearing that cache unnecessarily. Zooming in Dope Sheet (and a few others) does not actually change the font size so there is no reason to clear that cache in that case, hence the solution here: {d11f3267cd93} But zooming in the Node Editor(s) *does* change font size so the problem remains here. Fairly certain that just clearing all glyph caches **except** for the last one (first in the list) would help you, be a performance improvement, and would have not negative effects that I can think of off the top of my head. But I'll need to make sure. And if I'm going to touch this it might be nice to get slightly fancier and keep the last one **and** any that match the current global (non-zoomed areas) size. Realistically I'd hope to look at this within the next couple of weeks with the goal to (hopefully) have an improvement for the 2.6 release.

Harley Acheson commented

2023-02-02 18:34:16 +01:00

@nutti:

Separately from fixing above, is there anything about your use can that I can help?

I'm mostly just curious what you are using blf.dimension for. I can imagine a few text-related things that would be better solved on my end for you. For an example off the top of my head if you wanted to know the ideal text size to fit a string within a certain target width, that would be something I could do faster and provide a python function for.

@nutti: Separately from fixing above, is there anything about your use can that I can help? I'm mostly just curious what you are using `blf.dimension` for. I can imagine a few text-related things that would be better solved on my end *for you*. For an example off the top of my head if you wanted to know the ideal text size to fit a string within a certain target width, that would be something I could do faster and provide a python function for.

Harley Acheson commented

2023-02-02 21:33:41 +01:00

@nutti - This is my idea, in case you able to compile and test.

diff --git a/source/blender/blenfont/BLF_api.h b/source/blender/blenfont/BLF_api.h
index 558fd5f1dc21..154c231e9daa 100644
--- a/source/blender/blenfont/BLF_api.h
+++ b/source/blender/blenfont/BLF_api.h
@@ -33,8 +33,12 @@ struct rcti;
 int BLF_init(void);
 void BLF_exit(void);
 
+/* Delete all glyph caches. */
 void BLF_cache_clear(void);
 
+/* Delete all glyph caches except those matching the last-added size. */
+void BLF_cache_clean(void);
+
 /**
  * Optional cache flushing function, called before #blf_batch_draw.
  */
diff --git a/source/blender/blenfont/intern/blf.c b/source/blender/blenfont/intern/blf.c
index d4f5be617fd4..0d7ebd835784 100644
--- a/source/blender/blenfont/intern/blf.c
+++ b/source/blender/blenfont/intern/blf.c
@@ -89,6 +89,16 @@ void BLF_cache_clear(void)
   }
 }
 
+void BLF_cache_clean(void)
+{
+  for (int i = 0; i < BLF_MAX_FONT; i++) {
+    FontBLF *font = global_font[i];
+    if (font) {
+      blf_glyph_cache_clean(font);
+    }
+  }
+}
+
 bool blf_font_id_is_valid(int fontid)
 {
   return blf_get(fontid) != NULL;
@@ -277,7 +287,6 @@ void BLF_unload_all(void)
 void BLF_enable(int fontid, int option)
 {
   FontBLF *font = blf_get(fontid);
-
   if (font) {
     font->flags |= option;
   }
diff --git a/source/blender/blenfont/intern/blf_glyph.c b/source/blender/blenfont/intern/blf_glyph.c
index b95a48daccfe..84b174c74b5f 100644
--- a/source/blender/blenfont/intern/blf_glyph.c
+++ b/source/blender/blenfont/intern/blf_glyph.c
@@ -165,6 +165,28 @@ void blf_glyph_cache_clear(FontBLF *font)
   BLI_mutex_unlock(&font->glyph_cache_mutex);
 }
 
+void blf_glyph_cache_clean(FontBLF *font)
+{
+  /* Remove all glyph caches except those matching the size of last added (first) size. */
+  if (BLI_listbase_is_empty(&font->cache)) {
+    return;
+  }
+
+  BLI_mutex_lock(&font->glyph_cache_mutex);
+
+  GlyphCacheBLF *gc = (GlyphCacheBLF *)font->cache.first;
+  float last_size = gc->size;
+
+  LISTBASE_FOREACH_MUTABLE (GlyphCacheBLF *, gc, &font->cache) {
+    if (gc->size != last_size) {
+      BLI_remlink_safe(&font->cache, gc);
+      blf_glyph_cache_free(gc);
+    }
+  }
+
+  BLI_mutex_unlock(&font->glyph_cache_mutex);
+}
+
 /**
  * Try to find a glyph in cache.
  *
diff --git a/source/blender/blenfont/intern/blf_internal.h b/source/blender/blenfont/intern/blf_internal.h
index cbdfa1918774..687a216253c4 100644
--- a/source/blender/blenfont/intern/blf_internal.h
+++ b/source/blender/blenfont/intern/blf_internal.h
@@ -159,6 +159,7 @@ void blf_font_free(struct FontBLF *font);
 struct GlyphCacheBLF *blf_glyph_cache_acquire(struct FontBLF *font);
 void blf_glyph_cache_release(struct FontBLF *font);
 void blf_glyph_cache_clear(struct FontBLF *font);
+void blf_glyph_cache_clean(struct FontBLF *font);
 
 /**
  * Create (or load from cache) a fully-rendered bitmap glyph.
diff --git a/source/blender/editors/interface/view2d.cc b/source/blender/editors/interface/view2d.cc
index 51a3bd008af0..679c45dff0dd 100644
--- a/source/blender/editors/interface/view2d.cc
+++ b/source/blender/editors/interface/view2d.cc
@@ -1037,7 +1037,7 @@ void UI_view2d_zoom_cache_reset(void)
    * Not an issue with embedded font, but can use over 500Mb with i18n ones! See T38244. */
 
   /* NOTE: only some views draw text, we could check for this case to avoid cleaning cache. */
-  BLF_cache_clear();
+  BLF_cache_clean();
 }
 
 /** \} */
diff --git a/source/blender/makesrna/intern/rna_userdef.c b/source/blender/makesrna/intern/rna_userdef.c
index 7ebc5c425f5e..45a69cdf5a52 100644
--- a/source/blender/makesrna/intern/rna_userdef.c
+++ b/source/blender/makesrna/intern/rna_userdef.c
@@ -264,8 +264,8 @@ static void rna_userdef_dpi_update(Main *UNUSED(bmain),
                                    Scene *UNUSED(scene),
                                    PointerRNA *UNUSED(ptr))
 {
-  /* font's are stored at each DPI level, without this we can easy load 100's of fonts */
-  BLF_cache_clear();
+  /* Remove all glyph caches except for those matching the last-set size. */
+  BLF_cache_clean();
 
   WM_main_add_notifier(NC_WINDOW, NULL);             /* full redraw */
   WM_main_add_notifier(NC_SCREEN | NA_EDITED, NULL); /* refresh region sizes */

@nutti - This is my idea, in case you able to compile and test. ``` diff --git a/source/blender/blenfont/BLF_api.h b/source/blender/blenfont/BLF_api.h index 558fd5f1dc21..154c231e9daa 100644 --- a/source/blender/blenfont/BLF_api.h +++ b/source/blender/blenfont/BLF_api.h @@ -33,8 +33,12 @@ struct rcti; int BLF_init(void); void BLF_exit(void); +/* Delete all glyph caches. */ void BLF_cache_clear(void); +/* Delete all glyph caches except those matching the last-added size. */ +void BLF_cache_clean(void); + /** * Optional cache flushing function, called before #blf_batch_draw. */ diff --git a/source/blender/blenfont/intern/blf.c b/source/blender/blenfont/intern/blf.c index d4f5be617fd4..0d7ebd835784 100644 --- a/source/blender/blenfont/intern/blf.c +++ b/source/blender/blenfont/intern/blf.c @@ -89,6 +89,16 @@ void BLF_cache_clear(void) } } +void BLF_cache_clean(void) +{ + for (int i = 0; i < BLF_MAX_FONT; i++) { + FontBLF *font = global_font[i]; + if (font) { + blf_glyph_cache_clean(font); + } + } +} + bool blf_font_id_is_valid(int fontid) { return blf_get(fontid) != NULL; @@ -277,7 +287,6 @@ void BLF_unload_all(void) void BLF_enable(int fontid, int option) { FontBLF *font = blf_get(fontid); - if (font) { font->flags |= option; } diff --git a/source/blender/blenfont/intern/blf_glyph.c b/source/blender/blenfont/intern/blf_glyph.c index b95a48daccfe..84b174c74b5f 100644 --- a/source/blender/blenfont/intern/blf_glyph.c +++ b/source/blender/blenfont/intern/blf_glyph.c @@ -165,6 +165,28 @@ void blf_glyph_cache_clear(FontBLF *font) BLI_mutex_unlock(&font->glyph_cache_mutex); } +void blf_glyph_cache_clean(FontBLF *font) +{ + /* Remove all glyph caches except those matching the size of last added (first) size. */ + if (BLI_listbase_is_empty(&font->cache)) { + return; + } + + BLI_mutex_lock(&font->glyph_cache_mutex); + + GlyphCacheBLF *gc = (GlyphCacheBLF *)font->cache.first; + float last_size = gc->size; + + LISTBASE_FOREACH_MUTABLE (GlyphCacheBLF *, gc, &font->cache) { + if (gc->size != last_size) { + BLI_remlink_safe(&font->cache, gc); + blf_glyph_cache_free(gc); + } + } + + BLI_mutex_unlock(&font->glyph_cache_mutex); +} + /** * Try to find a glyph in cache. * diff --git a/source/blender/blenfont/intern/blf_internal.h b/source/blender/blenfont/intern/blf_internal.h index cbdfa1918774..687a216253c4 100644 --- a/source/blender/blenfont/intern/blf_internal.h +++ b/source/blender/blenfont/intern/blf_internal.h @@ -159,6 +159,7 @@ void blf_font_free(struct FontBLF *font); struct GlyphCacheBLF *blf_glyph_cache_acquire(struct FontBLF *font); void blf_glyph_cache_release(struct FontBLF *font); void blf_glyph_cache_clear(struct FontBLF *font); +void blf_glyph_cache_clean(struct FontBLF *font); /** * Create (or load from cache) a fully-rendered bitmap glyph. diff --git a/source/blender/editors/interface/view2d.cc b/source/blender/editors/interface/view2d.cc index 51a3bd008af0..679c45dff0dd 100644 --- a/source/blender/editors/interface/view2d.cc +++ b/source/blender/editors/interface/view2d.cc @@ -1037,7 +1037,7 @@ void UI_view2d_zoom_cache_reset(void) * Not an issue with embedded font, but can use over 500Mb with i18n ones! See T38244. */ /* NOTE: only some views draw text, we could check for this case to avoid cleaning cache. */ - BLF_cache_clear(); + BLF_cache_clean(); } /** \} */ diff --git a/source/blender/makesrna/intern/rna_userdef.c b/source/blender/makesrna/intern/rna_userdef.c index 7ebc5c425f5e..45a69cdf5a52 100644 --- a/source/blender/makesrna/intern/rna_userdef.c +++ b/source/blender/makesrna/intern/rna_userdef.c @@ -264,8 +264,8 @@ static void rna_userdef_dpi_update(Main *UNUSED(bmain), Scene *UNUSED(scene), PointerRNA *UNUSED(ptr)) { - /* font's are stored at each DPI level, without this we can easy load 100's of fonts */ - BLF_cache_clear(); + /* Remove all glyph caches except for those matching the last-set size. */ + BLF_cache_clean(); WM_main_add_notifier(NC_WINDOW, NULL); /* full redraw */ WM_main_add_notifier(NC_SCREEN | NA_EDITED, NULL); /* refresh region sizes */ ```

nutti commented

2023-02-04 12:54:43 +01:00

@Harley

Thanks for taking the action.
I tried your patch, but the issue is much worse than before.
When I tried zoom in/out, Blender will freeze.

I'm mostly just curious what you are using blf.dimension for.

I use blf.dimension for checking the max height of the characters provided from the font.
This can be solved by executing blf.dimensions(0, string.printable)[0].
So, I can achieve my task instead if you provide API like blf.maximum_height_in_fontset(font_id).

@Harley Thanks for taking the action. I tried your patch, but the issue is much worse than before. When I tried zoom in/out, Blender will freeze. > I'm mostly just curious what you are using blf.dimension for. I use blf.dimension for checking the max height of the characters provided from the font. This can be solved by executing blf.dimensions(0, string.printable)[0]. So, I can achieve my task instead if you provide API like blf.maximum_height_in_fontset(font_id).

Harley Acheson commented

2023-02-04 16:14:00 +01:00

@nutti - I use blf.dimension for checking the max height of the characters provided from the font.

But for what purpose?

I ask because the "max height provided in the font" is not the same as the height of the string.printable, which is something like "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!"#$%&'()*+, -./:;<=>?@- [x]^_`{|}~".

You might want an "average" height of the font, to make sure that what you want to display will fit somewhere. But in that case you can just use the font size itself. The font size is also the size in pixels of the font's EM square at that size. It can be considered both the "nominal height" and "nominal width" of the font. If you just compare the result you are getting now with the size itself you will find a very close and linear relationship.

You might really want the height of that "printable" string, in which case you could probably take the height of "Hy" and be done in a fraction of the time, since you are doing so in a process that is clearing all the caches and therefore we must render all the glyphs in that string while the font size changes.

You might truly want the maximum height of the all the glyphs in the font, which is easy to get from the font but will likely be larger than what you are expecting because it will include characters outside that printable range. But you really need to consider the height of ⾼ as well?

This can be solved by executing blf.dimensions(0, string.printable)[0].

Isn't that the length of the string since dimensions returns width then height?

> @nutti - I use blf.dimension for checking the max height of the characters provided from the font. But for what purpose? I ask because the "max height provided in the font" is not the same as the height of the string.printable, which is something like "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!"#$%&'()*+, -./:;<=>?@- [x]^_`{|}~". You might want an "average" height of the font, to make sure that what you want to display will fit somewhere. But in that case you can just use the font size itself. The font size is also the size in pixels of the font's EM square at that size. It can be considered both the "nominal height" and "nominal width" of the font. If you just compare the result you are getting now with the size itself you will find a very close and linear relationship. You might really want the height of that "printable" string, in which case you could probably take the height of "Hy" and be done in a fraction of the time, since you are doing so in a process that is clearing all the caches and therefore we must render all the glyphs in that string while the font size changes. You might truly want the maximum height of the all the glyphs in the font, which is easy to get from the font but will likely be larger than what you are expecting because it will include characters outside that printable range. But you really need to consider the height of ⾼ as well? > This can be solved by executing `blf.dimensions(0, string.printable)[0]`. Isn't that the *length* of the string since dimensions returns width then height?

nutti commented

2023-02-05 01:06:18 +01:00

@Harley

I need to use blf.dimension to get the actual rendering height because font_size is not the entire size for the actual rendering size.
string.printable does not cover all characters as you told, but string.printable is enough for the current purpose.

You might really want the height of that "printable" string, in which case you could probably take the height of "Hy" and be done in a fraction of the time, since you are doing so in a process that is clearing all the caches and therefore we must render all the glyphs in that string while the font size changes.

This matches my purpose. I only know the height of string.printable.
I'm not sure that specifying only "Hy" can get the maximum height of the string.printable.
Is this still works for non-default font?

blf.dimensions(0, string.printable)[0]

Sorry, I mistook about the code.
The correct one is blf.dimensions(0, string.printable)- [x] as you pointed out.

@Harley I need to use blf.dimension to get the actual rendering height because font_size is not the entire size for the actual rendering size. string.printable does not cover all characters as you told, but string.printable is enough for the current purpose. > You might really want the height of that "printable" string, in which case you could probably take the height of "Hy" and be done in a fraction of the time, since you are doing so in a process that is clearing all the caches and therefore we must render all the glyphs in that string while the font size changes. This matches my purpose. I only know the height of string.printable. I'm not sure that specifying only "Hy" can get the maximum height of the string.printable. Is this still works for non-default font? > blf.dimensions(0, string.printable)[0] Sorry, I mistook about the code. The correct one is blf.dimensions(0, string.printable)- [x] as you pointed out.

Harley Acheson commented

2023-02-05 19:16:54 +01:00

@nutti wrote:
I need to use blf.dimension to get the actual rendering height because font_size is not the entire size for the actual rendering size.
string.printable does not cover all characters as you told, but string.printable is enough for the current purpose.

Hmmm... you only get the "actual rendering height" of text if you measure that actual text, not a placeholder string like string.printable. So I'll assume that you are actually wanting the minimum height that can vertically contain any characters printed at a certain size? If you are attempting to guess the size of any UI elements note that they will be directly related to font size, not the measured height of any text. As in the header height of nodes and the line-spacing is not less if the text involved does not have ascenders or descenders, so the same amount whether the text is tall or short.

As mentioned the font size itself is directly and linearly-related to the measurement you want. If you find that is slightly too small for your use just add some wriggle room to it, as in use font size * 1.04 or so and you will get the same value you are testing for now without any measuring.

If you insist on measuring something, despite knowing it is not necessary, using all of sting.printable is not needed. You are only wanting the height so testing things like a "+" or "a" or "e" isn't adding anything. As mentioned earlier testing "Hy" will work for giving you a value for height of the alphanumeric characters (0-9,a-z,A-Z). If you want to include symbols then using something like "|" will give you the maximum in string.printable. Personally I'd use "Hy|" if I wasn't able to use font size directly.

> @nutti wrote: > I need to use blf.dimension to get the actual rendering height because font_size is not the entire size for the actual rendering size. > string.printable does not cover all characters as you told, but string.printable is enough for the current purpose. Hmmm... you only get the "actual rendering height" of text if you measure that *actual text*, not a placeholder string like string.printable. So I'll assume that you are actually wanting the minimum height that can vertically contain any characters printed at a certain size? If you are attempting to guess the size of any UI elements note that they will be directly related to font size, not the measured height of any text. As in the header height of nodes and the line-spacing is not less if the text involved does not have ascenders or descenders, so the same amount whether the text is tall or short. As mentioned the font size itself is directly and linearly-related to the measurement you want. If you find that is slightly too small for your use just add some wriggle room to it, as in use `font size * 1.04` or so and you will get the same value you are testing for now without any measuring. If you insist on measuring something, despite knowing it is not necessary, using all of sting.printable is not needed. You are only wanting the height so testing things like a "+" or "a" or "e" isn't adding anything. As mentioned earlier testing "Hy" will work for giving you a value for height of the alphanumeric characters (0-9,a-z,A-Z). If you want to include symbols then using something like "``|" will give you the maximum in string.printable. Personally I'd use "Hy``|" if I wasn't able to use font size directly.

nutti commented

2023-02-06 06:54:50 +01:00

@Harley

Thanks for your instruction.
blf.dimensions(0, "Hy|") works good without any lagging.
I think this workaround is enough for my use case.

BTW, how do we conclude this issue?
If other API user does the similar thing, this issue needs to be discussed again.

@Harley Thanks for your instruction. `blf.dimensions(0, "Hy|")` works good without any lagging. I think this workaround is enough for my use case. BTW, how do we conclude this issue? If other API user does the similar thing, this issue needs to be discussed again.

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

The execution time of blf.dimension is slow on Node Editor #104274