simon-git: putty (main): Ben Harris

[Commits to Tartarus hosted VCS]

TL;DR:
  c93a225b GTK: use cairo_paint() to copy from backing store to screen
  daed7200 GTK: create backing Cairo surface of similar type to window
  1ebca75a GTK: make inst->pixmap and inst->surface mutually exclusive
  8260ea22 GTK: disable GTK double-buffering of terminal drawing area
  08bc6703 GTK: never deliberately create an image surface for Cairo rendering
  9bd1b234 GTK: purely server-side X bitmap font rendering with Cairo
  c3e2bf98 GTK: clean up old X/Cairo font rendering code
  10fdd29f GTK: clear target Pixmap for X font rendering with Cairo
  82da46d2 GTK: remove most of the scale-factor support
  d1a56d67 GTK: use C99 designated initialisers to set up XGCValues
  dae2febd GTK: don't try to turn off double-buffering on GTK 1

Repository:     https://git.tartarus.org/simon/putty.git
On the web:     https://git.tartarus.org/?p=simon/putty.git
Branch updated: main
Committer:      Ben Harris <bjh21 at bjh21.me.uk>
Date:           2025-04-30 10:09:55

commit c93a225b979e67bc04a9443104ab5505e9299d2e
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=c93a225b979e67bc04a9443104ab5505e9299d2e;hp=01043ce4fc90cee578a00872a64fd69e4bb7203a
Author: Ben Harris <bjh21 at bjh21.me.uk>
Date:   Thu Apr 10 10:09:07 2025 +0100

    GTK: use cairo_paint() to copy from backing store to screen
    
    I just found cairo_paint() while wandering the Cairo documentation.  It
    just fills the entire clip region with data from the current source,
    which is precisely what draw_area() wants to do.  This is simpler for us
    than requesting the bounding rectangle of the clipping region and then
    filling it, and as far as I can tell the clipping rectangle generally
    covers the whole window anyway.

 unix/window.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

commit daed7200b33f710853e8d2f0792c3ede596754ef
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=daed7200b33f710853e8d2f0792c3ede596754ef;hp=c93a225b979e67bc04a9443104ab5505e9299d2e
Author: Ben Harris <bjh21 at bjh21.me.uk>
Date:   Sat Apr 19 09:13:06 2025 +0100

    GTK: create backing Cairo surface of similar type to window
    
    Specifically, this creates the surface using
    gdk_window_create_similar_surface() where that's available.

 unix/window.c | 6 ++++++
 1 file changed, 6 insertions(+)

commit 1ebca75a89deb456da8f39a0804cb021f72c955e
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=1ebca75a89deb456da8f39a0804cb021f72c955e;hp=daed7200b33f710853e8d2f0792c3ede596754ef
Author: Ben Harris <bjh21 at bjh21.me.uk>
Date:   Sun Apr 20 11:08:59 2025 +0100

    GTK: make inst->pixmap and inst->surface mutually exclusive
    
    This removes the case where we draw into a Cairo surface and then copy
    the results into a GdkPixmap.  Now, if we've got a GdkPixmap, we just
    draw into it directly using Cairo.  This vastly reduces the number of
    CopyArea operations needed to draw on the screen.

 unix/unifont.h |  6 ++++--
 unix/window.c  | 47 +++++++++++++----------------------------------
 2 files changed, 17 insertions(+), 36 deletions(-)

commit 8260ea2237887da874c9e11958a050e1092a5de4
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=8260ea2237887da874c9e11958a050e1092a5de4;hp=1ebca75a89deb456da8f39a0804cb021f72c955e
Author: Ben Harris <bjh21 at bjh21.me.uk>
Date:   Sun Apr 20 12:32:50 2025 +0100

    GTK: disable GTK double-buffering of terminal drawing area
    
    By default, when we're asked to draw a GTK widget, GTK creates a
    temporary surface (a Pixmap under X) and redirects our rendering into
    that.  Then it blits that into the actual window.  This is silly for
    PuTTY because all that PuTTY does to render its drawing area is to
    blit into it from _another_ surface.  So now PuTTY asks GTK not to do
    that.  According to the GTK documentation, GTK as of 3.10 has
    completely restructured its drawing routines so that turning off
    double-buffering actually makes things worse and slower, so we turn it
    off only in GTK 2
    
    Still, this now means that painting text on the screen in GTK 2 causes
    precisely one CopyArea operation, which is what we want.

 unix/window.c | 9 +++++++++
 1 file changed, 9 insertions(+)

commit 08bc6703049b7ec53b4cd64fde663e69ec3c8580
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=08bc6703049b7ec53b4cd64fde663e69ec3c8580;hp=8260ea2237887da874c9e11958a050e1092a5de4
Author: Ben Harris <bjh21 at bjh21.me.uk>
Date:   Sun Apr 20 18:29:48 2025 +0100

    GTK: never deliberately create an image surface for Cairo rendering
    
    If gdk_window_create_similar_surface() isn't available, we now fall back
    to cairo_surface_create_similar().  This is relevant only on GTK between
    2.00 and 2.22 with deprecated calls disabled.

 unix/window.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

commit 9bd1b234a098e366a16a02dc87b22fb500060dd3
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=9bd1b234a098e366a16a02dc87b22fb500060dd3;hp=08bc6703049b7ec53b4cd64fde663e69ec3c8580
Author: Ben Harris <bjh21 at bjh21.me.uk>
Date:   Fri Apr 25 20:12:12 2025 +0100

    GTK: purely server-side X bitmap font rendering with Cairo
    
    This is a fairly radical change of how X bitmap fonts are handled when
    using Cairo for rendering.  Before, we would download each glyph to the
    client on first use and then composite those glyphs into the terminal's
    backing surface. This worked pretty well when we were keeping an image
    of the whole screen on the client anyway, but once I'd pushed all the
    other Cairo rendering onto the X server, it meant that the character
    bitmaps had to be repeatedly pushed to the X server.
    
    The new arrangement just renders each string into a temporary Pixmap
    using the usual X text-drawing calls and then asks Cairo to paste it
    into the main backing Pixmap.  It's tempting to draw the text straight
    into the backing Pixmap, but that would require dealing directly with
    X colour management.  This way, we get to leave colours in the hands
    of Cairo (and hence the Render extension).
    
    There are still fragments of the old system around.  Those should go
    in the next commit.

 unix/unifont.c | 133 ++++++++++++++++++++++++++-------------------------------
 1 file changed, 60 insertions(+), 73 deletions(-)

commit c3e2bf980ff379e91eea94fc4a05f326b742d635
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=c3e2bf980ff379e91eea94fc4a05f326b742d635;hp=9bd1b234a098e366a16a02dc87b22fb500060dd3
Author: Ben Harris <bjh21 at bjh21.me.uk>
Date:   Fri Apr 25 20:52:58 2025 +0100

    GTK: clean up old X/Cairo font rendering code
    
    This requires deferring creating the X graphics context until we have
    a suitable Pixmap to base it on.

 unix/unifont.c | 64 +++++++++++++++-------------------------------------------
 1 file changed, 16 insertions(+), 48 deletions(-)

commit 10fdd29feaf4e23a66d1a8c66ed50911246286ec
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=10fdd29feaf4e23a66d1a8c66ed50911246286ec;hp=c3e2bf980ff379e91eea94fc4a05f326b742d635
Author: Ben Harris <bjh21 at bjh21.me.uk>
Date:   Sat Apr 26 22:14:49 2025 +0100

    GTK: clear target Pixmap for X font rendering with Cairo
    
    CreatePixmap returns a Pixmap with undefined contents, and ImageText16
    doesn't quite erase the whole rectangle covered by the text (and hence
    the whole Pixmap.  So to be on the safe side we should make sure to
    erase the entire Pixmap before drawing the text.
    
    Conveniently, ImageText16 ignores the function specified in the GC, so
    we can set that to GXclear and avoid needing to change the GC
    thereafter.

 unix/unifont.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

commit 82da46d22ef15a7b84af0f608520c9f7005864ee
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=82da46d22ef15a7b84af0f608520c9f7005864ee;hp=10fdd29feaf4e23a66d1a8c66ed50911246286ec
Author: Ben Harris <bjh21 at bjh21.me.uk>
Date:   Sun Apr 27 14:43:50 2025 +0100

    GTK: remove most of the scale-factor support
    
    Now that we use gdk_window_create_similar_surface() to make our backing
    surface, most of the code to handle scale factors is unnecessary and
    indeed slightly harmful.  gdk_window_create_similar_surface() creates a
    surface suitable for use as backing for a window, so it already has the
    scale factor applied.  This means that it should be sized in nominal
    pixels, we can paint to it in nominal pixels, and the fact that it has
    the same extra resolution as the actual window is entirely transparent
    to us.
    
    Now the only reason we pay attention to the scale factor at all is to
    detect changes and use them as a prompt to re-create the backing
    surface.

 unix/window.c | 38 ++++----------------------------------
 1 file changed, 4 insertions(+), 34 deletions(-)

commit d1a56d67ccc1c8be985c80362a337a94adacf6e8
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=d1a56d67ccc1c8be985c80362a337a94adacf6e8;hp=82da46d22ef15a7b84af0f608520c9f7005864ee
Author: Ben Harris <bjh21 at bjh21.me.uk>
Date:   Sun Apr 27 14:55:12 2025 +0100

    GTK: use C99 designated initialisers to set up XGCValues
    
    I just think it looks nicer than a pile of assignments.

 unix/unifont.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

commit dae2febd85390bd2afb73604a210bccbf9f92924
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=dae2febd85390bd2afb73604a210bccbf9f92924;hp=d1a56d67ccc1c8be985c80362a337a94adacf6e8
Author: Ben Harris <bjh21 at bjh21.me.uk>
Date:   Wed Apr 30 09:56:07 2025 +0100

    GTK: don't try to turn off double-buffering on GTK 1
    
    Apparently GTK 1 lacks gtk_widget_set_double_buffered(), so it should
    be conditional on running GTK 2.

 unix/window.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)