MisterMusion

You already have access to device pixels, you just have to calculate it yourself.

Anti-aliasing is not a good solution for orthogonal lines with low device pixel ratios like 1.25 or 1.5. which will be around for a long time. Browsers disagree with you - they don't use anti-aliasing for orthogonal measurements, they round. Which means they do in fact pixel-snap.

I agree that it can be misused like using device pixels for UI, but my suggestions makes the distinction more explicit.

The biggest problem IMHO is how the unit system with regards to pixels and physical units is designed. A px is not a device pixel but a physical unit of length 1/96 inch. This nonsense is technical not a CSS-only thing but based on a 80s hack by Microsoft and Apple. As a result you can not specify device pixel sizes directly, (you have to calculate them from devicepixelratio in js), and physical units relate to UI scaling on screen.

A use case for specifying device pixel sizes are thin-lined grids, that can have inconsistent spacing and line width due rounding when you use px on hi-DPI.

How it should be (and OSes should do it) is:

- There is the device pixel e.g. "dp"

- There is a UI scaling unit "u" (the equivalent to CSS px, but not with a misleading name). It could be e.g. defined to be the height of a standard button. This is used for most screen-oriented elements, and u-based sizes can be optionally rounded to whole dp.

- There are physical units independent of u. There is a ratio of these to dp. For print the ratio is e.g. so that 1in = 300dp if it is a 300dpi print. For screen the ratio is based on the actual physical pixel density the OS can either derive from a display device, or the user calibrates it. Physical unit based sizes can optionally be rounded to whole dp.

- The user can obviously set the UI scaling and overwrite the physical unit scaling.

This way you can get display pixel based sizes simply and reliably, UI scaling is not based on a often misunderstood "virtual pixel", and physical objects can be displayed on screen with its actual size (or whatever scaling the user wants).

Enumerating all 7-Move solutions of today's puzzle, I expected some kind simple pattern, like some key moves with a few permutations. I found that it is far more complex:

- there are 1536 solutions

- almost all moves are useful, non are required

- for every row-xoring move there is exactly one column-xoring move that appears in the same number of solutions (and no move appears twice in a solution)

Here is the number of solutions a move appears in (0-based indices):

  C3→2    R2→3    0
  C3→1    R2→1    82
  C2→0    R3→0    93
  C0→3    R0→2    163
  C2→1    R3→1    342
  C1→3    R1→2    426
  C1→2    R1→3    558
  C3→0    R2→0    614
  C2→3    R3→2    640
  C1→0    R1→0    726
  C0→1    R0→1    810
  C0→2    R0→3    922