Proper Pane Grid spacing

[clarkmoody]

On low-DPI screens, the rounding order of operations made it impossible to produce an odd-pixel spacing. Specifying 1, for instance, produced zero space between panes.

This approach subtracts half the spacing from the first pane prior to rounding and uses the whole spacing for the second pane size and coordinate.

We're no longer pre-computing the halved_spacing and passing that around. Rather Axis::split operates on the full spacing.

[hecrj]

Thanks!

On low-DPI screens, the rounding order of operations made it impossible to produce an odd-pixel spacing. Specifying 1, for instance, produced zero space between panes.

I believe the spacing was there but, as the halved_spacing was subtracted after rounding, the resulting rectangles were not aligned to the logical pixel grid. This can happen as part of layouting, so it shouldn't be a problem!

The changes here align the bounds to the logical grid after subtracting the spacing. This is more desirable because it's easier for the renderer to target physical pixels when dealing with an integral scale factor. However, it won't fix the issue when using a non-integral one.

Thus, the real underlying problem remains unsolved: targetting physical pixels when the rendering primitives do not align perfectly with the pixel grid (clamping?). The fix should probably happen in the quad rendering pipeline in iced_wgpu. I will try to play with it.

[clarkmoody]

Thus, the real underlying problem remains unsolved: targetting physical pixels when the rendering primitives do not align perfectly with the pixel grid (clamping?). The fix should probably happen in the quad rendering pipeline in iced_wgpu. I will try to play with it.

Might be a configuration option. SVG has the shape-rendering attribute, which may take the value crispEdges. There we find:

To achieve crisp edges, the user agent might turn off anti-aliasing for all lines and curves or possibly just for straight lines which are close to vertical or horizontal. Also, the user agent might adjust line positions and line widths to align edges with device pixels.

[hecrj]

@clarkmoody I believe quads should always be pixel-aligned, independently of the anti-aliasing strategy. They are GUI rendering primitives that should always be crisp.

The Mesh primitive, together with the antialiasing flag in Settings, can be leveraged to render geometry with subpixel precision.

I have opened #362 which should fix the main issue here. I still believe we should merge this, though!

[hecrj]

Awesome! Thank you 🎉