Page MenuHome

UI: Radial control values get wrong color assigned
Closed, ResolvedPublic

Description

System Information
Operating system: Linux-5.13.0-7620-generic-x86_64-with-glibc2.33 64 Bits
Graphics card: NVIDIA RTX A5000/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 470.82.00

Blender Version
Broken: version: 3.1.0 Alpha, branch: master, commit date: 2021-11-01 15:52, hash: rBadc540cf7ccf
Worked: Not sure as it was "hidden" by theme settings.

Short description of error

This is a very weird one. I just noticed that the radial control values (e.g. Shift+F in Sculpt or Weight Paint mode) in the 3D Viewport were using theme settings from the Dopesheet (Text Highlight or TEXT_HI in the code).

If I switch the bottom editor to Graph Editor, the radial control values now use TEXT_HI from the Graph Editor theme settings.

So it seems that the 3D Viewport is picking up theme settings from the editor below (Dopesheet and Timeline share the same theme settings). If the editor is removed and added again, this doesnt happen. I suspect it has something to do with a corrupt startup or memory issues.

Reporting this as it can be a sign of a deeper issue. Maybe the layouts need to be recreated again or reset?

Video showing the issue:

Exact steps for others to reproduce the error

  • Under Preferences -> Theme, change the color of Text Highlightinside Dopesheet ->Theme Space. Pick a strong color, like pink
  • In the Layout workspace, enter Weight Paint mode and press Shift+F to change the brush strength, you should see the strength values in pink

The expected result is to always use TEXT_HI from the 3D Viewport settings.

Event Timeline

Can confirm on 2.92, 2.91.2, 2.90.1
Can't confirm on 2.80 and 2.83.16.

So it seems that the 3D Viewport is picking up theme settings from the editor below (Dopesheet and Timeline share the same theme settings). If the editor is removed and added again, this doesnt happen. I suspect it has something to do with a corrupt startup or memory issues.

It's more complicated than that but somehow more or less consistent.
Order of priority in which Text Highlight in 3D viewport area are replaced by editor in other area is:

  1. timeline area below;
  2. outliner area in top tight corner;
  3. properties area in bottom right;

There is list of editors that trigger this bug. If one item on priority list changed to an editor that does not trigger bug, that item is ignored.
3D viewport area does not affect other areas (except new ones, see below). In fact, you can change other areas to 3D viewport and they follow same order of priority except for the ones above them (hard to explain properly, hang in there, examples incoming).
If you change outliner area to 3D viewport editor, it'll have Text Highlight of properties area. Timeline area does not affect it since it's above it, but it affects 3D viewport area. So you can have different Text Highlight in different 3D Viewport editor at the same time...

New areas does not take part in this priority list as in there is still only 3 areas that can replace Text Highlight of other areas. But those new areas still affected by bug but their priority list looking like this:

  1. 3D viewport area;
  2. timeline area;
  3. outliner area;
  4. properties area.

So they have one extra item here, and they affected by this regardless where they are. Try this:

  • create new area (doesn't matter where or how many);
  • change 3D viewport area to, say, Dope Sheet editor;
  • change timeline area to 3D Viewport editor;
  • change outliner area to Graph editor.

Now on Shift+F Text Highlight in all new areas is same as in Dope Sheet but for 3D Viewport in timeline area it's same as in Graph editor.

List of editors that can trigger this bug:

  1. Dope Sheet
  2. Timeline (as stated before, Dope Sheet and Timeline share the same theme settings)
  3. Graph
  4. Drivers (Graph and Drivers share the same theme settings
  5. Video Sequencer
  6. Nonlinear Animation

I could also check what other settings except Text Highlight are affected but nah, too much

Committed a fix to master now. We could backport this to the 3.0 release branch, but I'd prefer not to since it may affect the theme colors of other overlays.

Thanks Garek for the research and Julian for the quick fix!