simon-git: putty (master): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  b72f0ba Force GTK1 build to use -std=gnu89.
  1ca03a1 gtkwin: factor out drawing_area_setup_simple().
  383302d GTK 3: be aware of the window's scale factor.

Repository:     https://git.tartarus.org/simon/putty.git
On the web:     https://git.tartarus.org/?p=simon/putty.git
Branch updated: master
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2018-05-11 09:51:55

commit b72f0baed67de7f434c409056c3da5bca10629c5
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=b72f0baed67de7f434c409056c3da5bca10629c5;hp=412dce1e8add7dfc9d3c49505c422381aec3cc84
Author: Simon Tatham <anakin at pobox.com>
Date:   Fri May 11 08:15:46 2018 +0100

    Force GTK1 build to use -std=gnu89.
    
    Every time I do my standard re-test against all three major versions
    of GTK, I have to annoyingly remember that the GTK1 headers contain
    code that depends on the old gcc language standard, and manually add
    this flag on the configure command line. Time to put it where it
    belongs, in configure.ac so I don't have to remember it again.

 configure.ac | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

commit 1ca03a186f80fcb2b05d650c9870da0e587dff3d
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=1ca03a186f80fcb2b05d650c9870da0e587dff3d;hp=b72f0baed67de7f434c409056c3da5bca10629c5
Author: Simon Tatham <anakin at pobox.com>
Date:   Fri May 11 09:00:46 2018 +0100

    gtkwin: factor out drawing_area_setup_simple().
    
    I'm about to want to do this operation from more places, so here's a
    minor NFC refactoring that will simplify the next commit.

 unix/gtkwin.c | 28 +++++++++++++++++++---------
 1 file changed, 19 insertions(+), 9 deletions(-)

commit 383302d70ad5ade17e9c451b6468e588d676bbd7
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=383302d70ad5ade17e9c451b6468e588d676bbd7;hp=1ca03a186f80fcb2b05d650c9870da0e587dff3d
Author: Simon Tatham <anakin at pobox.com>
Date:   Fri May 11 07:53:05 2018 +0100

    GTK 3: be aware of the window's scale factor.
    
    In GTK 3.10 and above, high-DPI support is arranged by each window
    having a property called a 'scale factor', which translates logical
    pixels as seen by most of the GTK API (widget and window sizes and
    positions, coordinates in the "draw" event, etc) into the physical
    pixels on the screen. This is handled more or less transparently,
    except that one side effect is that your Cairo-based drawing code had
    better be able to cope with that scaling without getting confused.
    
    PuTTY's isn't, because we do all our serious drawing on a separate
    Cairo surface we made ourselves, and then blit subrectangles of that
    to the window during updates. This has two bad consequences. Firstly,
    our surface has a size derived from what GTK told us the drawing area
    size is, i.e. corresponding to GTK's _logical_ pixels, so when the
    scale factor is (say) 2, our drawing takes place at half size and then
    gets scaled up by the final blit in the draw event, making it look
    blurry and unpleasant. Secondly, those final blits seem to end up
    offset by half a pixel, so that a second blit over the same
    subrectangle doesn't _quite_ completely wipe out the previously
    blitted data - so there's a ghostly rectangle left behind everywhere
    the cursor has been.
    
    It's not that GTK doesn't _let_ you find out the scale factor; it's
    just that it's in an out-of-the-way piece of API that you have to call
    specially. So now we do: our backing surface is now created at a pixel
    resolution matching the screen's real pixels, and we translate GTK's
    scale factor into an ordinary cairo_scale() before we commence
    drawing. So we still end up drawing the same text at the same size -
    and this strategy also means that non-text elements like cursor
    outlines and underlining will be scaled up with the screen DPI rather
    than stubbornly staying one physical pixel thick - but now it's nice
    and sharp at full screen resolution, and the subrectangle blits in the
    draw event are back to affecting the exact set of pixels we expect
    them to.
    
    One silly consequence is that, immediately after removing the last
    one, I've installed a handler for the GTK "configure-event" signal!
    That's because the GTK 3 docs claim that that's how you get notified
    that your scale factor has changed at run time (e.g. if you
    reconfigure the scale factor of a whole monitor in the GNOME settings
    dialog). Actually in practice I seem to find out via the "draw" event
    before "configure" bothers to tell me, but now I've got a usefully
    idempotent function for 'check whether the scale factor has changed
    and sort it out if so', I don't see any harm in calling it from
    anywhere it _might_ be useful.

 unix/gtkwin.c | 94 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 87 insertions(+), 7 deletions(-)