Adds axonometric grid

[pedropaulosuzuki]

Implements #1438. Does not implement color and angle changes (fixed #000 and 45deg). Does implement size, though.

Please squash the commits.

[pedropaulosuzuki]

@cameronwhite I tried everything, but the formatting continues to fail. Any ideas? 😵‍💫

[pedropaulosuzuki]

Here's a video of the axonometric grid + scaling. (Also showing no regression on regular grid).

Screencast.from.13-06-2025.20.13.33.webm

Btw, you can even stack the axonometric grid on top of the regular grid, if you so desire:

[pedropaulosuzuki]

Does not implement color and angle changes (fixed #000 and 45deg).

I tried to implement angle changes, but was getting some problems with floating point rounding errors, so I'll keep that to a future merge request.

[cameronwhite]

Looks great! Just one a minor comment on code style

[Lehonti]

What do you guys think of hiding/showing the respective spin buttons depending on the checked/unchecked status of the checkboxes? From my research, I think it would be easy to implement through value bindings.

I believe these are not currently used in Pinta, but could help us make the code tidy if used correctly, and this could be a good place to try a pilot of it.

A summary I found says:

GTK value bindings provide a mechanism to automatically synchronize the values of properties on different objects, or between a property and an expression

So imagine binding the Visible property of the width/height spin buttons to the property (I think Active?) of the "Show Grid" checkbox that indicates if it's checked or not.

[cameronwhite]

👍 I don't have any objection to using value bindings for this if it's easy to set up (if not, just using some regular event handlers isn't difficult either)
I'd prefer having them disabled rather than hidden (like the Resize Image dialog) so that the window size doesn't jump around though

[pedropaulosuzuki]

What do you guys think of hiding/showing the respective spin buttons depending on the checked/unchecked status of the checkboxes? From my research, I think it would be easy to implement through value bindings.

I believe these are not currently used in Pinta, but could help us make the code tidy if used correctly, and this could be a good place to try a pilot of it.

A summary I found says:

GTK value bindings provide a mechanism to automatically synchronize the values of properties on different objects, or between a property and an expression

So imagine binding the Visible property of the width/height spin buttons to the property (I think Active?) of the "Show Grid" checkbox that indicates if it's checked or not.

What about using a checkbox with a GTK expander? I think showing/hiding the Spin Buttons without animation would look quite bad, but the expander probably fixes that.

👍 I don't have any objection to using value bindings for this if it's easy to set up (if not, just using some regular event handlers isn't difficult either) I'd prefer having them disabled rather than hidden (like the Resize Image dialog) so that the window size doesn't jump around though

I'm also ok with disabling the inputs.

[cameronwhite]

Thanks! The comments look fine to me 👍

I think let's just disable the inputs here since there aren't many widgets

[pedropaulosuzuki]

I think let's just disable the inputs here since there aren't many widgets

Done!

[pedropaulosuzuki]

Todo for future MR: Only render any grid lines inside viewport boundaries to improve performance.

If we add a regular grid or an axonometric grid (or both) with size 1 when zoomed in, we get a lot of lag. That's because our loops consider the whole canvas for grid line creation, and not only the viewport area.

[cameronwhite]

The binding changes look good, thank you!

[cameronwhite]

Todo for future MR: Only render any grid lines inside viewport boundaries to improve performance.

If we add a regular grid or an axonometric grid (or both) with size 1 when zoomed in, we get a lot of lag. That's because our loops consider the whole canvas for grid line creation, and not only the viewport area.

Re: performance, one other thing to try out would be caching the Gsk.Path for the grid. It really only needs to be rebuilt when the grid settings change, or the canvas size changes, but currently it's built on every redraw.