Unnecessary truncation of parameter names in nodes #102687
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
6 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#102687
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
System Information
Operating system: Windows-10-10.0.22000-SP0 64 Bits
Graphics card: NVIDIA RTX A2000 Laptop GPU/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 526.67
Blender Version
Broken: version: 3.3.0, branch: master, commit date: 2022-09-06 15:39, hash:
0759f671ceWorked: never
Short description of error
Unnecessary truncation of parameter names in nodes happens at certain zoom levels in the node editor.
Exact steps for others to reproduce the error
I use these the below theme settings. Unsure if other settings cause the same issue. Replicate by copying settings, adding some nodes in any editor and play with the zoom level to watch words truncate in and out randomly.
Edit: Minimum steps to reproduce:
For good measure, I tried it in 2.93 LTS. It didn't have sub-point sizes yet, but the problem also appears at larger sizes than default.
Added subscriber: @Claus
Unnecessary truncation of parameters in nodesto Unnecessary truncation of parameter names in nodesAdded subscriber: @OmarEmaraDev
Changed status from 'Needs Triage' to: 'Needs User Info'
I can't reproduce that on any zoom level. Does this happen with the default font and user preferences?
After some experimentation, I think I found the cause: setting the Widget Label text size to 12.0. Neither different type of hinting nor switching to the default font seemed to influence the problem. Only when changing size from 11.0 to 12.0 did the problem appear. In fact, it starts at 11.5 and up.
Default font at 12.0:
12.0:
Seemingly any node:
11.0:
Can't reproduce with 12pt widget label and the rest of the preferences set to defaults. What resolution is your monitor?
Same issue on all three:
Changed status from 'Needs User Info' to: 'Needs Triage'
Added subscriber: @mano-wii
Changed status from 'Needs Triage' to: 'Needs User Info'
@Claus, could you find the minimum steps to reproduce the problem? Otherwise it becomes too time consuming for us to track down. We require the bug reporter to narrow down the problem.
Normally .blend files can be simplified by removing most objects and disabling settings, until the problem reveals itself more clearly.
Also please attach a .blend file with the node groups created, so only a few steps are needed to trigger the bug.
I could, but I think downloading the .blend would be more trouble than retracing the steps on your end since the issue isn't with a particular file or nodegroup. I'll update the original post with minimum steps:
For good measure, I tried it in 2.93 LTS. It didn't have sub-point sizes yet, but the problem also appears at larger sizes than default.
Changed status from 'Needs User Info' to: 'Confirmed'
I can confirm the problem
The greater the value of {nav Widget Label > Points} the greater the problem.
(Note to devs: not to confuse with the
Pointsproperty inPanel TitleorWidget)Added subscriber: @lone_noel
I've investigated this a bit.
The core issue seems to be that the function
ui_text_icon_width_exthat calculates the width of the label button always uses thewidgetfont style while the socket label is drawn based on thewidgetlabelfont style.So when making the text size of widget labels ({nav Widget Label > Points}) larger than the text size of widgets ({nav Widget > Points}) the calculated button width is too narrow to fit the label and it gets clipped.
Sidenote: The reason this doesn't happen for input sockets or a lot of the labels using the property split layout, is that the layout for those happens to be aligned in a way so the label buttons always take up the entire width of the layout, which hides the issue...
I'm not yet sure, what's the cleanest fix, but it shouldn't be too involved.
Do I understand correctly that a widget label is coded as a button whose graphic is invisible? Better question: Is there a resource for correct programming terminology for Blender's interface elements that I can learn from? It is unclear to me what a "label button" is.
Added subscriber: @Harley
Yes, but that is not really the issue here. Internally almost all Blender UI elements are a type of
UiBut, with differing flags, so you will sometimes hear us talk of "buttons" for things that are not really buttons. So yes, a widget label and a button you click on are internally represented by the same things with different behaviors.This issue is to do with "Styles", specifically Text Styles. If you go to Preferences / Themes / Text Style you will see that you can change the size of different UI elements independent of the overall UI scale. You can make it so that regardless of scale you always have Header text twice as large as regular text, for example.
But the design is not fleshed out well. We have just "Panel Title", "Widget", and "Widget Label". There are many areas where one type of UIBut uses one when it should use another. There are assumptions, like in this complaint, that "Widget" and "Widget Label" are the same size. The function mentioned -
ui_text_icon_width_ex- is trying to estimate an element's width but does not have the information needed to know what style to use, so just uses UI_FSTYLE_WIDGET, which is hardcoded for the "widget" style.Personally I'm not sure of a good long-term solution. This particular problem runs so deep that I would be inclined to just merge "Widget" and "Widget Label" text styles, leaving us with only two styles "Header" and "Widget". And then probably add a third back for "Tool Tips" because that text size is currently set as a hardcoded fraction of the widget size - and I can imagine some users with vision impairment wanting those proportionally larger.
After looking into it a bit more I tend to agree.
Passing the font style into
ui_text_icon_width_exand using the widget label style in a few places fixes the issue here (and another place I noticed) but I wouldn't be confident to say it's fixed in all cases (P3345).It's also the kind of thing that easily breaks since you have to make sure the font styles stay in sync in the various places.
+1