simon-git: puzzles (main): Ben Harris

[Commits to Tartarus hosted VCS]

TL;DR:
  6a0d142 Describe front-end pixel scaling in devel.but
  986ac69 js: handle most of the device pixel ratio in the front end
  86fc307 js: replace blitters array with a Map
  b04e5b3 js: index blitters Map by C address of blitter structure
  49aad96 js: trust CanvasRenderingContext2D.drawImage() to DTRT

Repository:     https://git.tartarus.org/simon/puzzles.git
On the web:     https://git.tartarus.org/?p=simon/puzzles.git
Branch updated: main
Committer:      Ben Harris <bjh21 at bjh21.me.uk>
Date:           2025-05-13 23:43:02

commit 6a0d142f426e868bec99ea50c2d82d88ae7fdfac
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=6a0d142f426e868bec99ea50c2d82d88ae7fdfac;hp=50985e9f2c54ad44e8c26491ddddd698bc02fd06
Author: Ben Harris <bjh21 at bjh21.me.uk>
Date:   Sun May 11 11:56:02 2025 +0100

    Describe front-end pixel scaling in devel.but
    
    This adds two paragraphs.  The first describes the model that the GTK
    front-end uses, where a "pixel" in the drawing API can map to multiple
    pixels in the pixmap used for drawing.  To preserve pixel-accuracy,
    this requires that there be an integer number of physical pixels to
    each logical pixel, which happily is the case in GTK (at least up to
    GTK 3).
    
    The second paragraph attempts to explain how this relates to the
    device_pixel_ratio provided to midend_size().  That's used by the
    JavaScript front end and can cope with the arbitrary non-integer scale
    factors thatr might be provided by Web browsers.  However, it works by
    just exposing physical pixels to the back end, which means that thin
    lines tend to become hard to see as the physical pixels get small.
    
    I think the best approach is actually a mixture of the two, where an
    integer is factored out of the scale factor by the front end, and the
    remaining factor (which should be < 2) is passed to midend_size().  I
    haven't tried implementing this yet, though, so I might change my
    mind.

 devel.but | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

commit 986ac69fb9ec5aaad04bc256c33d6ae4b3c0a13f
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=986ac69fb9ec5aaad04bc256c33d6ae4b3c0a13f;hp=6a0d142f426e868bec99ea50c2d82d88ae7fdfac
Author: Ben Harris <bjh21 at bjh21.me.uk>
Date:   Mon May 12 23:02:20 2025 +0100

    js: handle most of the device pixel ratio in the front end
    
    This makes the JavaScript front end work more like the GTK front end in
    its handling of varying device pixel ratios, which GTK calls scale
    factors.  This is also an implementation of what I just described in
    devel.but.
    
    If the device pixel ratio is an integer, then the mid and back ends just
    ge told about CSS logical pixels and the front end handles all the
    necessary scaling itself, much like GTK.  If the device pixel ratio
    isn't an integer then this isn't possible.  Instead we handle scaling by
    the floor of the device pixel ratio in the front end, and pass the
    remaining scaling factor to the mid end as the device pixel ratio.  This
    means that pressing Ctrl-+ in a browser still causes the canvas to grow
    nicely, but on reaching a zoom of 200% the thin lines all get thicker.
    
    I think this is a more or less ideal way to handle the device pixel
    ratio, and in particular produces decent results without any effort in
    back ends and without complicating the drawing API.  It does need rather
    a lot of front-end work, though.

 emcc.c     | 52 ++++++++++++++++++++++++++++++++++++++++++----------
 emcclib.js | 16 ++++++++++++++--
 emccpre.js | 15 +++++++++++++--
 3 files changed, 69 insertions(+), 14 deletions(-)

commit 86fc307f1956643dcb51965077f97b6548e6de6b
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=86fc307f1956643dcb51965077f97b6548e6de6b;hp=986ac69fb9ec5aaad04bc256c33d6ae4b3c0a13f
Author: Ben Harris <bjh21 at bjh21.me.uk>
Date:   Tue May 13 20:25:00 2025 +0100

    js: replace blitters array with a Map
    
    The array was growing by one element each time the puzzle was resized in
    Guess, so is was a (minor) memory leak.  The Map shouldn't have that
    problem, though eventually the "id" counter will overflow.

 emcclib.js | 13 +++++++------
 emccpre.js |  2 +-
 2 files changed, 8 insertions(+), 7 deletions(-)

commit b04e5b3531a8e08f2b884d42509e3bddb6f0291a
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=b04e5b3531a8e08f2b884d42509e3bddb6f0291a;hp=86fc307f1956643dcb51965077f97b6548e6de6b
Author: Ben Harris <bjh21 at bjh21.me.uk>
Date:   Tue May 13 20:49:13 2025 +0100

    js: index blitters Map by C address of blitter structure
    
    C pointers appear as numbers in JavaScript and so they can be used to
    index a Map.  This removes the (admittedly rather theoretical) danger of
    overflowing the blitter ID by repeatedly allocating and deallocating
    blitters.

 emcc.c     | 17 ++++++++---------
 emcclib.js | 29 ++++++++++++++---------------
 2 files changed, 22 insertions(+), 24 deletions(-)

commit 49aad96bb553fcc19f0535923b4ba0117f412902
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=49aad96bb553fcc19f0535923b4ba0117f412902;hp=b04e5b3531a8e08f2b884d42509e3bddb6f0291a
Author: Ben Harris <bjh21 at bjh21.me.uk>
Date:   Tue May 13 22:52:49 2025 +0100

    js: trust CanvasRenderingContext2D.drawImage() to DTRT
    
    As far as I can tell, the specification for
    CanvasRenderingContext2D.drawImage() requires it to sensibly handle
    cases where the rectangle it's working on isn't entirely contained in
    both the source and destination canvases.  So there's not really any
    reason for Puzzles to carefully trim the region being copied to their
    intersection.  This vastly simplifies a lot of the blitter-handling code
    because it can just ask the user agent to copy the whole blitter back
    and forth.
    
    I've checked archived versions of the HTML spec back to 2014, and they
    all say this should work.  MDN doesn't suggest otherwise either.  So I
    think if this code was ever necessary, it's not any more.

 emcc.c     | 52 +++++++---------------------------------------------
 emcclib.js | 16 ++++++----------
 2 files changed, 13 insertions(+), 55 deletions(-)