Regression: Nodes: Background dots clipping is visible #114110
Background dots in node editor are clipped by borders.
But that clipping is not correct on too large zoom.
Fix: Deduce the reason of that behavior, and change iteration amount to +1 or add zoom factor multiplication in somethere.
Yes, I struggled with clipping of those dots. Before my patch (which was more about the sizing and placement of them) there were many times that they would be shown on top of the scroll bar, which I really hated. Fairly certain (away from computer) that in the example above the next column of them would in the space used by the scroll bar. That the scroll bar is not currently show makes it look odd, but not as odd as having dots on the scroll bar. It’s a fun bit of code if you want to try to improve it.
Ah, yes, I know this struggle well from some web apps I've worked on in my day job. The dynamic-width translucent "floating" scrollbars are so pretty and modern, but quite a pain when they clash with the background content.
That said, the dots are definitely clipping farther from the scrollbars than they need to be. In this screenshot, I've panned so the dots near the scrollbars are as close as they can get before they clip (and both scrollbars are active and at full width):
Looks like there's an extra scrollbar width/height being added to the margin.
Anyway, I'll try taking a look at this while everyone else is busy with BCON 2023
The link to my PR above should point you at the code nicely and you’ll probably find it fun to play with.
The complications here are how we want things to scale. Generally we want everything scaling linearly. But… we also have “line width” adjustment which we use like a “minimum feature size”, so small things like lines become thicker independent of interface scaling. In this case with the dot grid we want the line width to affect the size of each dot but only use ui scale for the dot placement.
For this particular issue, if we want to make sure the dots don’t show in the scroll bar space you need to make sure this applies when you change scale and when selecting “wide lines” because that makes those wider. There is probably a function somewhere that returns the current width of that region’s scroll bar so you can probably get as you accurate as you can stand. I think, but not sure, that those dots might be changing their opacity near that edge so they don’t just pop in and out abruptly.
Anyway, there’s lots in there to have fun with. Don’t hesitate to ask questions.
In this case with the dot grid we want the line width to affect the size of each dot
Hm? No, i don't see the issues in the fact that dot's is drawn under scrollbar.
In the fact, i'd not like idea of changing grid density by hovering cursor over scrollbar.
Thanks, @Harley! I definitely respect the complexity here, and I appreciate you taking the time to explain it (in the midst of BCON 2023, no less!). If I'm able to make an improvement here, it will only be because I have the luxury of investing as much time as I choose—no pressure to move on to other priorities.
Looks like this is just a matter of needing to scale
V2D_SCROLL_WIDTH based on the zoom factor.
I created #114219 with that fix, but there is maybe one more detail to work out...
I can fix that by also subtracting the dot radius from the rectangle's width/height, but there's a catch:
- If I subtract the point radius for the current grid level, then we can get cases where larger dots clip, but the smaller dots underneath them are not clipped.
- If I instead subtract
max_point_sizethen I've made the margin a bit bigger than it needs to be in most cases.
So @Harley please let me know if you'd like me to add one of those two adjustments to my PR, or if it's fine to allow that little bit of overlap.
I'd also like to add that I personally don't think this clipping around the scrollbars is necessary at all. I think it looks perfectly fine for the grid dots to go underneath the scrollbars, just like it's fine for the nodes and noodles to be underneath them.
@Harley I posted a question for you in one of my previous comments, but I suspect it may have slipped through the cracks as it was in the midst of the conference. Could you take a look when you get a chance?
No due date set.
No dependencies set.
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?