WIP: UI: Node Dashed Lines Readability #110124

Closed

Harley Acheson wants to merge 1 commits from Harley/blender:NodeDashedLines into main

When changing the target branch, be careful to rebase the branch in your fork to match. See documentation.

Harley Acheson commented

2023-07-15 02:04:53 +02:00

Member

Make Node dashed lines thicker, with wider fully-transparent gaps.

Our current "dashed lines" shader in the Node editors creates lines with gaps that are about a single pixel in width and with only a 50% opacity drop. On retina displays this gap is subpixel in size and hard to see.

This PR makes the gaps larger (50% of each section verses 25%), makes them fully transparent instead of 50%, and makes the lines wider. The following illustrates the changes. This has been saved at a larger size then reduced to 50% in order to simulate the pixel sizes on a high-DPI display:

Make Node dashed lines thicker, with wider fully-transparent gaps. --- Our current "dashed lines" shader in the Node editors creates lines with gaps that are about a single pixel in width and with only a 50% opacity drop. On retina displays this gap is subpixel in size and hard to see. This PR makes the gaps larger (50% of each section verses 25%), makes them fully transparent instead of 50%, and makes the lines wider. The following illustrates the changes. This has been saved at a larger size then reduced to 50% in order to simulate the pixel sizes on a high-DPI display: ![NodeDashed.gif](/attachments/75ecce9b-becb-4592-8a94-543ff8c855d3)

NodeDashed.gif

33 KiB

Harley Acheson added 1 commit 2023-07-15 02:05:00 +02:00

27bdf6d1bf UI: Node Dashed Lines Readability

Make Node dashed lines thicker, with wider fully-transparent gaps.

Harley Acheson added this to the User Interface project 2023-07-15 02:05:22 +02:00

Harley Acheson requested review from Hans Goudey 2023-07-15 02:05:31 +02:00

Iliya Katushenock added the

Nodes & Physics

labels 2023-07-15 13:00:12 +02:00

Leon Schittek commented

2023-07-17 07:58:49 +02:00

Member

Thanks for taking this on. While these defaults are certainly more readable, I still find it very easy to get kinda bad results on mac OS depending on zoom and resolution scale (see screenshots below).

Regarding your following comment in #102919 (comment):

But as we increase Resolution scale we should see a decrease in the dash frequency but instead we get an increase.

I remember being confused by this, too, but I think I now understand what's going on:
When increasing the resolution scale, the drawn nodes - just like the rest of the UI - actually get bigger and spaced further apart (see how node_to_view or NODE_WIDTH() use the UI_SCALE_FAC).
As a result, a link that's e.g. 100 units long becomes 200 units long when doubling the resolution scale. Since the dashes have a fixed lenght, twice many dashes now fit along the length of the link, so it looks like the dash frequency increases when viewing the nodes at the same size on screen.

Maybe we could pass a dash_width parameter into the shader, so we can easily calculate the length of the dashes taking the resolution scale into account. That would be similar to how it's already done with the link's thinkness.

Resolution Scale	Screenshot
0.5
1.0
2.0

Thanks for taking this on. While these defaults are certainly more readable, I still find it very easy to get kinda bad results on mac OS depending on zoom and resolution scale (see screenshots below). Regarding your following comment in https://projects.blender.org/blender/blender/issues/102919#issuecomment-917731: >But as we increase Resolution scale we should see a decrease in the dash frequency but instead we get an increase. I remember being confused by this, too, but I think I now understand what's going on: When increasing the resolution scale, the drawn nodes - just like the rest of the UI - actually get bigger and spaced further apart (see how `node_to_view` or `NODE_WIDTH()` use the `UI_SCALE_FAC`). As a result, a link that's e.g. 100 units long becomes 200 units long when doubling the resolution scale. Since the dashes have a fixed lenght, twice many dashes now fit along the length of the link, so it looks like the dash frequency increases when viewing the nodes at the same size on screen. Maybe we could pass a `dash_width` parameter into the shader, so we can easily calculate the length of the dashes taking the resolution scale into account. That would be similar to how it's already done with the link's thinkness. --- |Resolution Scale|Screenshot| |---|---| |**0.5**|![field-links_ui-scale-05.png](/attachments/aeb6c36a-613e-44fa-aed7-93e232182778)| |**1.0**|![field-links_ui-scale-10.png](/attachments/7ca08a39-cd73-4c9e-ada1-83169017c77c)| |**2.0**|![field-links_ui-scale-20.png](/attachments/2dcb23c3-8a01-4760-95b3-9572a73df6c7)|

field-links_ui-scale-20.png

395 KiB

field-links_ui-scale-10.png

322 KiB

field-links_ui-scale-05.png

249 KiB

Harley Acheson commented

2023-07-18 01:01:03 +02:00

Author

Member

@lone_noel - Maybe we could pass a dash_width parameter into the shader, so we can easily calculate the length of the dashes taking the resolution scale into account. That would be similar to how it's already done with the link's thinkness.

Do mind taking a look at that? I've spent many an hour in gpu_shader_2D_nodelink_vert.glsl and could not figure out what to change that would affect the dash width.

> @lone_noel - Maybe we could pass a `dash_width` parameter into the shader, so we can easily calculate the length of the dashes taking the resolution scale into account. That would be similar to how it's already done with the link's thinkness. Do mind taking a look at that? I've spent many an hour in `gpu_shader_2D_nodelink_vert.glsl` and could not figure out what to change that would affect the dash width.

Leon Schittek commented

2023-07-18 07:45:10 +02:00

Member

Do mind taking a look at that? I've spent many an hour in gpu_shader_2D_nodelink_vert.glsl and could not figure out what to change that would affect the dash width.

Totally know that feeling from dealing with shaders. I got something working that should be good enough to get an impression.

After some recent changes to OpenGL I can't actually run main blender on my (very old) macbook anymore, so I won't be able to make a PR before I've sorted that out. But the attached diff compiles on main and should give results like in the screenshots below.

I kept the current line thickness and dash spacing just to see if that is still readable enough.

One thing I noticed is that, while the dash spacing now works ok on higher resolution scales, the line thickness is still a bit inconsistent and the sides of the links get very blurry. So still room for improvement.

Resolution Scale	Screenshot (diff)
0.5
1.0
2.0

> Do mind taking a look at that? I've spent many an hour in `gpu_shader_2D_nodelink_vert.glsl` and could not figure out what to change that would affect the dash width. Totally know that feeling from dealing with shaders. I got something working that should be good enough to get an impression. After some recent changes to OpenGL I can't actually run main blender on my (very old) macbook anymore, so I won't be able to make a PR before I've sorted that out. But the attached diff compiles on main and should give results like in the screenshots below. I kept the current line thickness and dash spacing just to see if that is still readable enough. One thing I noticed is that, while the dash spacing now works ok on higher resolution scales, the line thickness is still a bit inconsistent and the sides of the links get very blurry. So still room for improvement. --- |Resolution Scale|Screenshot (diff)| |---|---| |**0.5**|![nodelink-dash-test-05.png](/attachments/40a1c9fb-1a19-4cd3-a1b7-b0dcd8204309)| |**1.0**|![nodelink-dash-test-10.png](/attachments/7df25686-fa88-4419-9216-d5a169f59e66)| |**2.0**|![nodelink-dash-test-20.png](/attachments/4f16a3c8-040a-4fe2-babe-fc502e65e306)|

nodelink-dash-width.diff

8.3 KiB

nodelink-dash-test-05.png

217 KiB

nodelink-dash-test-10.png

262 KiB

nodelink-dash-test-20.png

296 KiB

Harley Acheson changed title from ~~UI: Node Dashed Lines Readability~~ to WIP: UI: Node Dashed Lines Readability

2023-07-18 17:29:26 +02:00

Harley Acheson commented

2023-07-19 01:03:27 +02:00

Author

Member

One thing I noticed is that, while the dash spacing now works ok on higher resolution scales, the line thickness is still a bit inconsistent and the sides of the links get very blurry. So still room for improvement.

Yes, while playing with this I could get something I liked at 1.0 resolution scale that worked as the 2D zoom was changed. But as soon as I change the UI resolution to 2.0 the line widths and thickness then looked wonky. I couldn't get any combination that looked good regardless of zoom and scale.

> One thing I noticed is that, while the dash spacing now works ok on higher resolution scales, the line thickness is still a bit inconsistent and the sides of the links get very blurry. So still room for improvement. Yes, while playing with this I could get something I liked at 1.0 resolution scale that worked as the 2D zoom was changed. But as soon as I change the UI resolution to 2.0 the line widths and thickness then looked wonky. I couldn't get any combination that looked good regardless of zoom and scale.

Hans Goudey commented

2023-07-24 20:35:12 +02:00

Member

For the opacity, the first version was 0/1 like this, but we changed it to its current state so it's less distracting. The idea is to reduce the amount of noise when there are tons of these links, possibly even overlapping. It may not work great for everyone though, so maybe it should be tunable.

For the opacity, the first version was 0/1 like this, but we changed it to its current state so it's less distracting. The idea is to reduce the amount of noise when there are tons of these links, possibly even overlapping. It may not work great for everyone though, so maybe it should be tunable.

Harley Acheson commented

2023-07-25 19:28:05 +02:00

Author

Member

For the opacity, the first version was 0/1 like this, but we changed it to its current state so it's less distracting. The idea is to reduce the amount of noise when there are tons of these links, possibly even overlapping. It may not work great for everyone though, so maybe it should be tunable.

The problem really isn't the amount of gap in the dash or how transparent the gap is, and changing this was just a (failed) attempt to make it more readable.

The central issue is really the width of the dashed lines and the number of of them between any two points. Although this looks okay on regular monitors it doesn't scale up correctly on high-dpi monitors, like those typically found now on Macs. On those systems the lines stay narrow and the gaps between the dashes get tiny.

I have yet to find a way to change the shader to work as I would like and am now just hoping Leon has better luck.

> For the opacity, the first version was 0/1 like this, but we changed it to its current state so it's less distracting. The idea is to reduce the amount of noise when there are tons of these links, possibly even overlapping. It may not work great for everyone though, so maybe it should be tunable. The problem really isn't the amount of gap in the dash or how transparent the gap is, and changing this was just a (failed) attempt to make it more readable. The central issue is really the width of the dashed lines and the number of of them between any two points. Although this looks okay on regular monitors it doesn't scale up correctly on high-dpi monitors, like those typically found now on Macs. On those systems the lines stay narrow and the gaps between the dashes get tiny. I have yet to find a way to change the shader to work as I would like and am now just hoping Leon has better luck.

Leon Schittek commented

2023-08-13 23:03:21 +02:00

Member

I think I've now managed to get the links to display completely consistent independent of the resoultion scale. This should already help with the dashes on high-dpi monitors.

I also tried to improve the readability of the dashed lines in general, but it seems like a hard thing to really get right.
One approach I found promising is to keep the size of the dashes constant in screen space, to sidestep the issue of the dashes becoming too small, which is hard to avoid considering the range of zoom in the node editor:

dash type	screenshot
viewspace constant (current) - the dashes become indistinguishable when zoomed out too far
screenspace constant - the dashes stay readable

I've only got a hacky prototype, but blending between different sizes of the dash pattern based on the zoom seems to work pretty well - similarly to the dot grid in the background.

It can look a bit trippy when focusing on it during zooming (first video), but if found that in practice you're usually zooming in bursts which makes the blending not that noticable (second video).

I find it increases the readability of the dashed links quite a lot when zoomed out, so I'm curious about your thoughts.

I think I've now managed to get the links to display completely consistent independent of the resoultion scale. This should already help with the dashes on high-dpi monitors. I also tried to improve the readability of the dashed lines in general, but it seems like a hard thing to really get right. One approach I found promising is to keep the size of the dashes constant in screen space, to sidestep the issue of the dashes becoming too small, which is hard to avoid considering the range of zoom in the node editor: |dash type|screenshot| |---|---| |**viewspace constant (current)** - the dashes become indistinguishable when zoomed out too far|![nodelink-dashes_viewspace-constant.png](/attachments/d822e957-3bbc-42d5-a4b5-d8542f04eb59)| |**screenspace constant** - the dashes stay readable|![nodelink-dashes_screenspace-constant.png](/attachments/85790b8a-345b-48a2-b971-4f854ac5743b)| I've only got a hacky prototype, but blending between different sizes of the dash pattern based on the zoom seems to work pretty well - similarly to the dot grid in the background. It can look a bit trippy when focusing on it during zooming (first video), but if found that in practice you're usually zooming in bursts which makes the blending not that noticable (second video). <video src="/attachments/d2c3e683-c847-4ac4-b33c-88ff1347b91f" title="zoom_screenspace-constant.mp4" controls></video> <video src="/attachments/a70260bf-4839-4812-9a3f-5924a9b18bc2" title="zoom_nodetree-test.mp4" controls></video> I find it increases the readability of the dashed links quite a lot when zoomed out, so I'm curious about your thoughts.

zoom_nodetree-test.mp4

1.9 MiB

nodelink-dashes_viewspace-constant.png

235 KiB

zoom_screenspace-constant.mp4

521 KiB

nodelink-dashes_screenspace-constant.png

234 KiB

Harley Acheson commented

2023-08-13 23:28:37 +02:00

Author

Member

Hey that does seem nicer. So glad you have been working on this.

Although it is just better for these to be more readable, my own primary concern is really about how they look on retina displays. So how these look at various zoom levels while also having the Preferences / Resolution Scale set to 2.0 (assuming you have a regular monitor yourself). Set like that we are trying to have all features (line width, gaps between, etc) no smaller than 2 pixels. Bonus point if the features get even larger with "Line Width" set to "Thick" lines (feature size of U.pixelsize). We have some users with eyesight impairment who find this quite important so this is an accessibility issue.

Once you have a PR to test we can make some test builds and let them test it.

Hey that does seem nicer. So glad you have been working on this. Although it is just better for these to be more readable, my own _primary_ concern is really about how they look on retina displays. So how these look at various zoom levels while also having the Preferences / Resolution Scale set to 2.0 (assuming you have a regular monitor yourself). Set like that we are trying to have all features (line width, gaps between, etc) no smaller than 2 pixels. Bonus point if the features get even larger with "Line Width" set to "Thick" lines (feature size of U.pixelsize). We have some users with eyesight impairment who find this quite important so this is an accessibility issue. Once you have a PR to test we can make some test builds and let them test it.

Leon Schittek commented

2023-08-13 23:54:12 +02:00

Member

So how these look at various zoom levels while also having the Preferences / Resolution Scale set to 2.0 (assuming you have a regular monitor yourself). Set like that we are trying to have all features (line width, gaps between, etc) no smaller than 2 pixels. Bonus point if the features get even larger with "Line Width" set to "Thick" lines (feature size of U.pixelsize).

Great to have all that spelled out so clearly. Will look into that and get things ready for testing. I have a day off on friday, so probably then.

> So how these look at various zoom levels while also having the Preferences / Resolution Scale set to 2.0 (assuming you have a regular monitor yourself). Set like that we are trying to have all features (line width, gaps between, etc) no smaller than 2 pixels. Bonus point if the features get even larger with "Line Width" set to "Thick" lines (feature size of U.pixelsize). Great to have all that spelled out so clearly. Will look into that and get things ready for testing. I have a day off on friday, so probably then.

Harley Acheson commented

2023-08-23 01:36:18 +02:00

Author

Member

Closing. Leon has a better solution, now merged. #111270

Closing. Leon has a better solution, now merged. https://projects.blender.org/blender/blender/pulls/111270

Harley Acheson closed this pull request

2023-08-23 01:36:20 +02:00

Pull request closed

Please reopen this pull request to perform a merge.

Sign in to join this conversation.

No reviewers

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#110124

No description provided.