clone

an offline sliding-block puzzle game in gleam and lustre, with an endless ladder of puzzles ranked by search

Intensity prints the picture, it does not lay it out

Dami committed 7906417
Turning the shading down changed the size of every word on screen. On a phone at
390x844 the upscale went from 1.5 to 2, on a 1440x900 laptop from 4.5 to 3, and
on a 1920x1080 one from 3 to 4 — and the chrome is sized in layout units times
that upscale, so a third was added to or taken off every button, every label and
every rule in the DOM. Five of twelve ordinary window sizes did it.

The cause is one argument. The ladder of crisp upscales is density*k/dpr, so it
is cut differently for each density: at dpr 2 the standard density offers 1.5, 3
and 4.5, and the low one offers 1, 2, 3 and 4. `choose` was handed whichever
density the setting was on, so a control over how the picture is *printed* was
picking which layout the app got.

It is handed the standard density now, always. The ladder stops moving, and the
setting does what its label says. The default path is untouched — the standard
density is what it was already choosing from — so this only ever moves the low
setting, and it moves it onto the layout the app was going to have anyway.

What is left: at an upscale where scale*dpr is odd, 1.5 and 4.5 on a dpr 2
screen, a low-density buffer pixel now covers one and a half device pixels
rather than a whole number of them, so the ground's ruling goes slightly uneven
there. That is a shading artifact in the setting that asks for coarser shading,
which is the right place for it to land, and it is a much smaller thing than
relaying out the app.
commit
7906417dea964b0b722c4cfd6847888f9cb8a399
parent
02af01d6be57a4f79795f82536d5b4c98b4872d5
author
Dami <dami.etoile@gmail.com>
2 files changed, +18 -4
Msrc/klotski.gleam7+++++--
Msrc/klotski/layout.gleam15+++++++++++++--
M src/klotski.gleam +5 -2
M src/klotski/layout.gleam +13 -2
@@ -333,6 +333,17 @@ fn metrics_for(mode: Mode, scale: Float, box: Box) -> Layout {
333333 /// same board size. They are what a display with dpr 2 and density 3 gets:334334 /// there is no k there that both lands whole and leaves the column wide enough,335335 /// and a board at half the size is a worse answer than a board that resamples.336+///337+/// The density here is the *standard* one and not whatever the intensity setting338+/// is on, which is a distinction that cost a whole layout. The ladder is cut339+/// from it — at dpr 2 a density of 3 offers 1.5, 3 and 4.5, and a density of 2340+/// offers 1, 2, 3 and 4 — so reading the setting here let a control over the341+/// shading pick a different winner and move every measurement in the app with342+/// it. On five of twelve ordinary window sizes, including a phone and two343+/// laptops, turning the intensity down changed the upscale, and everything the344+/// chrome sizes in layout units changed by a third along with it. Intensity is345+/// allowed to change how the picture is *printed* and nothing about how it is346+/// laid out.336347 fn upscales(dpr: Float, density: Int) -> List(#(Float, Bool)) {337348 let crisp =338349 [1, 2, 3, 4, 5, 6]
@@ -366,10 +377,10 @@ fn upscales(dpr: Float, density: Int) -> List(#(Float, Bool)) {
366377 /// leaves the column too narrow to hold, so crispness there would cost a quarter367378 /// of the board — which is the wrong trade, and a resampled board at full size368379 /// is what that display gets.369-pub fn choose(box: Box, dpr: Float, density: Int) -> Layout {380+pub fn choose(box: Box, dpr: Float, standard_density: Int) -> Layout {370381 let candidates =371382 list.flat_map([Stack, Split], fn(mode) {372- list.filter_map(upscales(dpr, density), fn(candidate) {383+ list.filter_map(upscales(dpr, standard_density), fn(candidate) {373384 let #(scale, crisp) = candidate374385 let m = metrics_for(mode, scale, box)375386 case m.vw < 150 || m.vw > 640 || m.vh < 120 {