WIP: UI: Automatic Text Contrast for Overlays #121239

Harley Acheson · 2024-04-30T03:05:47+02:00

Harley Acheson commented

2024-04-30 03:05:47 +02:00

Automatic text color and shadows to give contrast for text overlays.

This PR changes a few simple things:

BLF_shadow currently sets both the shadow strength and color. This PR alters it so that the shadow_color is optional, and is only set if is supplied. This means we can call this function to only change the strength without affecting the current shadow color.

BLF_draw_default_shadowed is altered similarly. It gains an optional shadow_color that is null by default, and this is what is passed to BLF_shadow. This way we can set the shadow color once and then later call BLF_draw_default_shadowed and have it use the same shadow color. The text color is already like this: we set it once and it stays like that until we change it.

With the above changes it means we can manufacture a text color and shadow color once and it will be used by all the overlay functions. These colors are picked based on the brightness of the 3DView background color, obtained from ED_view3d_background_color_get. If dark it uses white as text color with black shadow, if light is uses dark text with shadow color the same as the background color.

Set to WIP as I haven't tested this much yet.

Separately, because of a similar change in #121222, this PR also alters draw_vertical_scale_indicators. This is used to draw the text in the vertical axis of Graph Editor. This PR changes it to use the background color as shadow rather than a hard-coded black.

Automatic text color and shadows to give contrast for text overlays. --- This PR changes a few simple things: `BLF_shadow` currently sets both the shadow strength and color. This PR alters it so that the `shadow_color` is optional, and is only set if is supplied. This means we can call this function to only change the strength without affecting the current shadow color. `BLF_draw_default_shadowed` is altered similarly. It gains an optional `shadow_color` that is null by default, and this is what is passed to `BLF_shadow`. This way we can set the shadow color once and then later call `BLF_draw_default_shadowed` and have it use the same shadow color. The text color is already like this: we set it once and it stays like that until we change it. With the above changes it means we can manufacture a text color and shadow color once and it will be used by all the overlay functions. These colors are picked based on the brightness of the 3DView background color, obtained from `ED_view3d_background_color_get`. If dark it uses white as text color with black shadow, if light is uses dark text with shadow color the same as the background color. Set to WIP as I haven't tested this much yet. ![image](/attachments/8263af35-ae64-4525-bc92-9dc75ed74512) Separately, because of a similar change in #121222, this PR also alters `draw_vertical_scale_indicators`. This is used to draw the text in the vertical axis of Graph Editor. This PR changes it to use the background color as shadow rather than a hard-coded black.

image.png

87 KiB

Harley Acheson added 1 commit 2024-04-30 03:05:58 +02:00

9a75b82ec4 WIP: UI: Automatic Text Contrast for Overlays

Automatic text color and shadows to give contrast for text overlays.

Harley Acheson added this to the User Interface project 2024-04-30 03:10:13 +02:00

Harley Acheson requested review from Aras Pranckevicius 2024-04-30 03:10:44 +02:00

Aras Pranckevicius reviewed 2024-04-30 09:14:09 +02:00

source/blender/blenfont/BLF_api.hh

						
				@ -273,3 +273,3 @@

				 * Take care that shadow need to be enable using #BLF_enable!

				 */

				void BLF_shadow(int fontid, int level, const float rgba[4]) ATTR_NONNULL(3);

				void BLF_shadow(int fontid, int level, const float rgba[4] = nullptr) ATTR_NONNULL(3);

Aras Pranckevicius commented

2024-04-30 09:14:09 +02:00

You probably want to remove ATTR_NONNULL(3) since the argument very much allows and defaults to null now :)

You probably want to remove `ATTR_NONNULL(3)` since the argument very much allows and defaults to null now :)

Aras Pranckevicius commented

2024-04-30 09:26:12 +02:00

Overall nice, except I'm not quite sold on the white shadow color (I tried that in my other PR initially too, but the brain does not equate "bright color" as "this is a shadow", it looks more like "this is some glow").

In this PR, it does have some bright shadows which also looks similarly strange to me

I'm thinking that to be "really nice", maybe when the shadow color is brighter than the text color, it should actually try to do an "outline", not "a blur". But that sounds like a somewhat more involved change that would need a shader side change as well.

Overall nice, except I'm not quite sold on the white shadow color (I tried that in my other PR initially too, but the brain does not equate "bright color" as "this is a shadow", it looks more like "this is some glow"). In this PR, it does have some bright shadows which also looks similarly strange to me ![image](/attachments/bb9cfc8b-ff8a-4d69-8fe4-0babf9294377) I'm thinking that to be "really nice", maybe when the shadow color is brighter than the text color, it should actually try to do an "outline", not "a blur". But that sounds like a somewhat more involved change that would need a shader side change as well.

image.png

124 KiB

Harley Acheson commented

2024-04-30 18:35:48 +02:00

I'm thinking that to be "really nice", maybe when the shadow color is brighter than the text color, it should actually try to do an "outline", not "a blur". But that sounds like a somewhat more involved change that would need a shader side change as well.

Yes, a solid outline does always work better, but I (personally) don't have any good solutions for that.

I have tried that at the glyph creation stage. One attempt used FreeTypes "embolden" to expand out in all directions without otherwise changing the spacing. This worked well enough for this purpose. I also tried "stroking" (LOL), which involves adding a wider line around the glyph parts. This worked better, but both ways meant that I had to draw twice for each letter. Yes, I know we are now drawing twice with each letter but it is at least the exact same glyph, where this was something else that needed to be created and cached on its own (the same way if the letters differed in boldness, etc).

But when testing it there was in increase in contrast versus our shadowing, and it didn't look like a glow when lighter.

Could we do similar on the shader? Fairly certain that we have the ability to draw the characters at a different size than they are actually rendered (FontBLF ->aspect), although not sure I've seen us use this anywhere good (we do bad things with it in Geometry Node frame titles). But maybe just drawing the glyph at a larger size on the shader, with some magical left shift, could get us a solid version to use as a base for the regular glyph?

> I'm thinking that to be "really nice", maybe when the shadow color is brighter than the text color, it should actually try to do an "outline", not "a blur". But that sounds like a somewhat more involved change that would need a shader side change as well. Yes, a solid outline does always work better, but I (personally) don't have any good solutions for that. I have tried that at the glyph creation stage. One attempt used FreeTypes "embolden" to expand out in all directions without otherwise changing the spacing. This worked _well enough_ for this purpose. I also tried "stroking" (LOL), which involves adding a wider line around the glyph parts. This worked better, but both ways meant that I had to draw twice for each letter. Yes, I know we are now drawing twice with each letter but it is at least the exact same glyph, where this was something else that needed to be created and cached on its own (the same way if the letters differed in boldness, etc). But when testing it there was in increase in contrast versus our shadowing, and it didn't look like a glow when lighter. Could we do similar on the shader? Fairly certain that we have the ability to draw the characters at a different size than they are actually rendered (FontBLF ->aspect), although not sure I've seen us use this anywhere good (we do bad things with it in Geometry Node frame titles). But maybe just drawing the glyph at a larger size on the shader, with some magical left shift, could get us a solid version to use as a base for the regular glyph?

Aras Pranckevicius commented

2024-04-30 20:05:05 +02:00

I could try implementing an "outline" part of the text shader, which is not that different from a 5x5 blur, just with somewhat different weights. I'll play around with that and will report back, ok?

Harley Acheson commented

2024-04-30 20:20:16 +02:00

I could try implementing an "outline" part of the text shader, which is not that different from a 5x5 blur, just with somewhat different weights. I'll play around with that and will report back, ok?

That would be awesome! Although my (possibly wrong) reading is that we communicate the shadow size in a weird way to the shader. We pass a glyph-size int[2] where if both items are positive there is no shadow, but negative x and it is the 3pixel shadow, negative both to get the 5pixel shadow.

So maybe we could just make the current 3x3 shadow be an unblurred outline?

Or better we could add a new shadow level of "1" that uses positive x with negative y. If done well enough we could use this alone for all overlays and we'd no longer need my dumb BLF_draw_default_shadowed at all.

> I could try implementing an "outline" part of the text shader, which is not that different from a 5x5 blur, just with somewhat different weights. I'll play around with that and will report back, ok? That would be awesome! Although my (possibly wrong) reading is that we communicate the shadow size in a weird way to the shader. We pass a glyph-size int[2] where if both items are positive there is no shadow, but negative x and it is the 3pixel shadow, negative both to get the 5pixel shadow. So maybe we could just make the current 3x3 shadow be an unblurred outline? Or better we could add a new shadow level of "1" that uses positive x with negative y. If done well enough we could use this alone for all overlays and we'd no longer need my dumb BLF_draw_default_shadowed at all.

Aras Pranckevicius commented

2024-04-30 20:34:29 +02:00

is that we communicate the shadow size in a weird way to the shader

Yes it is weird, and could be done in a much nicer way. All that "pass extra bits via negative numbers" sounds like very dubious optimization, if you ask me. Possibly makes the shader a tiny bit slower, in fact :) What I would do, is to stop all that and just pass an integer to the shader for "shadow mode enum".

> is that we communicate the shadow size in a weird way to the shader Yes it is weird, and could be done in a much nicer way. All that "pass extra bits via negative numbers" sounds like very dubious optimization, if you ask me. Possibly makes the shader a tiny bit slower, in fact :) What I would do, is to stop all that and just pass an integer to the shader for "shadow mode enum".

Harley Acheson commented

2024-05-01 00:09:58 +02:00

I mentioned earlier that using FreeType embolden "worked well enough for this purpose." I found an old capture of those tests:

As shown it definitely worked good enough as a sharp outline. Blown up large you can see a defect with the "D" because of the way it moves the vector points.

And reversed it looks better than having a soft shadow:

I mentioned earlier that using FreeType embolden "worked _well enough_ for this purpose." I found an old capture of those tests: ![image](/attachments/cf206ff4-ec11-40b5-bcb1-029c89e2941f) As shown it definitely worked good enough as a sharp outline. Blown up large you can see a defect with the "D" because of the way it moves the vector points. And reversed it looks better than having a soft shadow: ![image](/attachments/21ecdb92-c0ff-4b07-9fad-983fe09e0c3a)

image.png

50 KiB

image.png

47 KiB

Aras Pranckevicius commented

2024-05-02 10:45:34 +02:00

What I have now looks like this:

i.e. this is based on the color choosing logic of this PR, but instead of various shadowing combinations, the "shadow" is actually a 1px outline by doing 3x3 dilation in the text shader (I tried 5x5 dilation too, but that feels "too much").

Is your thinking that the whole BLF_draw_default_shadowed thing (where it draws two shadows - 3x3 centered and 5x5 slightly offset) could/should be replaced by just a single outline?

What I have now looks like this: ![image](/attachments/673a6e3f-3a1e-48fd-8d18-b77de49e0a93) ![image](/attachments/8ad8dbfc-78fe-4185-9291-9aad111418e5) ![image](/attachments/2f46c5f2-0a43-4997-8abe-bdfa2a7a6066) i.e. this is based on the color choosing logic of this PR, but instead of various shadowing combinations, the "shadow" is actually a 1px outline by doing 3x3 dilation in the text shader (I tried 5x5 dilation too, but that feels "too much"). Is your thinking that the whole `BLF_draw_default_shadowed` thing (where it draws _two_ shadows - 3x3 centered and 5x5 slightly offset) could/should be replaced by just a single outline?

image.png

46 KiB

image.png

40 KiB

image.png

40 KiB

Harley Acheson commented

2024-05-02 14:41:58 +02:00

What I have now looks like this:

Wow, that looks as good as when I was was (attempting) to make outlined glyphs in Freetype. My results were good still required drawing twice and with different glygh caches so not worth it.

the "shadow" is actually a 1px outline by doing 3x3 dilation in the text shader (I tried 5x5 dilation too, but that feels "too much")

That’s what found as well.

Is your thinking that the whole BLF_draw_default_shadowed thing (where it draws two shadows - 3x3 centered and 5x5 slightly offset) could/should be replaced by just a single outline?

At the very least that default_shadowed thing could go away but unsure of how. Using our current shadow width would simple - using this a “1”?

> What I have now looks like this: Wow, that looks as good as when I was was (attempting) to make outlined glyphs in Freetype. My results were good still required drawing twice and with different glygh caches so not worth it. > the "shadow" is actually a 1px outline by doing 3x3 dilation in the text shader (I tried 5x5 dilation too, but that feels "too much") That’s what found as well. > Is your thinking that the whole `BLF_draw_default_shadowed` thing (where it draws _two_ shadows - 3x3 centered and 5x5 slightly offset) could/should be replaced by just a single outline? At the very least that default_shadowed thing could go away but unsure of how. Using our current shadow width would simple - using this a “1”?

Aras Pranckevicius commented

2024-05-02 19:54:56 +02:00

At the very least that default_shadowed thing could go away but unsure of how. Using our current shadow width would simple - using this a “1”?

Right now in my hacky code it is "6". TBH I don't quite like the current "level" where the only valid options are 0, 3 or 5, that feels more like enum and less like "shadow level". In my mind, ideally it would be changed to something like:

C++ code: instead of "int level", it would take an enum ShadowType { Simple, Blur3x3, Blur5x5, Outline }
Python API: continues to accept integer 0, 3, 5 amounts (which map to appropriate levels), but also accepts string enum-like values that map to the C++ enum values.

One "uhh" thing left is that "outline" does not feel like a "shadow" much.

> At the very least that default_shadowed thing could go away but unsure of how. Using our current shadow width would simple - using this a “1”? Right now in my hacky code it is "6". TBH I don't quite like the current "level" where the only valid options are 0, 3 or 5, that feels more like enum and less like "shadow level". In my mind, ideally it would be changed to something like: - C++ code: instead of "int level", it would take an `enum ShadowType { Simple, Blur3x3, Blur5x5, Outline }` - Python API: continues to accept integer 0, 3, 5 amounts (which map to appropriate levels), but also accepts string enum-like values that map to the C++ enum values. One "uhh" thing left is that "outline" does not feel like a "shadow" much.

Aras Pranckevicius referenced this pull request

2024-05-03 08:37:20 +02:00

BLF: fade out shadow when text color itself is dark #121222

Aras Pranckevicius referenced this pull request

2024-05-03 09:49:48 +02:00

UI: Automatic text contrast for overlays via outline #121383

Aras Pranckevicius commented

2024-05-03 09:53:21 +02:00

I didn't know how to make a PR that builds upon your PR, so I created a new one: #121383. Let me know if 1) it makes sense, and 2) I should redo it in some other way.

Harley Acheson commented

2024-05-05 23:18:32 +02:00

Closing in favor of #121383

Harley Acheson closed this pull request

2024-05-05 23:18:34 +02:00

Pull request closed

Please reopen this pull request to perform a merge.

Sign in to join this conversation.

No reviewers

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

WIP: UI: Automatic Text Contrast for Overlays #121239

Pull request closed