simon-git: putty (master): Simon Tatham

Sat Aug 15 21:12:55 BST 2015

TL;DR:
  0f60287 Stop multifont fallback from crashing in GTK1.
  f750a18 Refactor the GTK drawing system to do both GDK and Cairo.
  3c912e7 Withdraw the horrible bodge in make_mouse_ptr().

Repository:     git://git.tartarus.org/simon/putty.git
On the web:     http://tartarus.org/~simon-git/gitweb/?p=putty.git
Branch updated: master
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2015-08-15 21:12:55

commit 0f60287f66c7a0586304709ae002249e092ef05e
web diff http://tartarus.org/~simon-git/gitweb/?p=putty.git;a=commitdiff;h=0f60287f66c7a0586304709ae002249e092ef05e;hp=f3f215423bca59a0f09483db973d5ddc44d3d041
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Aug 15 20:26:07 2015 +0100

    Stop multifont fallback from crashing in GTK1.

    I was tacitly assuming that mfont->fallback would always be non-NULL,
    which is true in a world containing Pango, but untrue in GTK1 when
    Pango isn't there. In that situation we fall back to just omitting the
    characters that would be displayed in the fallback font, on the
    grounds that that's better than dereferencing through a NULL vtable.

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

commit f750a185873eba65f0fbb95dce204b0941f3cc25
web diff http://tartarus.org/~simon-git/gitweb/?p=putty.git;a=commitdiff;h=f750a185873eba65f0fbb95dce204b0941f3cc25;hp=0f60287f66c7a0586304709ae002249e092ef05e
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Aug 15 21:05:56 2015 +0100

    Refactor the GTK drawing system to do both GDK and Cairo.

    We're going to have to use Cairo in the GTK3 port, because that's all
    GTK3 supports; but we still need old-style GDK for GTK1 support, and
    also for performance reasons in GTK2 (see below). Hence, this change
    completely restructures GTK PuTTY's drawing code so that there's a
    central 'drawing context' structure which contains a type code
    indicating GDK or Cairo, and then either some GDK gubbins or some
    Cairo gubbins as appropriate; all actual drawing is abstracted through
    a set of routines which test the type code in that structure and do
    one thing or another. And because the type code is tested at run time,
    both sets of drawing primitives can be compiled in at once, and where
    possible, they will be.

    X server-side bitmap fonts are still supported in the Cairo world, but
    because Cairo drawing is entirely client-side, they have to work by
    cheekily downloading each glyph bitmap from the server when it's first
    needed, and building up a client-side cache of 'cairo_surface_t's
    containing the bitmaps with which we then draw on the window. This
    technique works, but it's rather slow; hence, even in GTK2, we keep
    the GDK drawing back end compiled in, and switch over to it when the
    main selected font is a bitmap one.

    One visible effect of the new Cairo routines is in the double-width
    and double-height text you can get by sending ESC # 3, ESC # 4 and
    ESC # 6 escape sequences. In GDK, that's always been done by a really
    horrible process of manually scaling the bitmap, server-side, column
    by column and row by row, causing each pixel to be exactly doubled or
    quadrupled. But in Cairo, we can just set a transformation matrix, and
    then that takes effect _before_ the scalable fonts are rendered - so
    the results are visibly nicer, and use all the available resolution.

    (Sadly, if you're using a server-side bitmap font as your primary one,
    then the GDK backend will be selected for all drawing in the terminal
    as a whole - so in that situation, even fallback characters absent
    from the primary font and rendered by Pango will get the old GDK
    scaling treatment. It's only if your main font is scalable, so that
    the Cairo backend is selected, that DW/DH characters will come out
    looking nice.)

 unix/gtkask.c  |   56 ++++--
 unix/gtkfont.c |  578 ++++++++++++++++++++++++++++++++++++++++++++------------
 unix/gtkfont.h |   80 +++++++-
 unix/gtkwin.c  |  397 +++++++++++++++++++++++++++++---------
 4 files changed, 880 insertions(+), 231 deletions(-)

commit 3c912e799430a3803d46dc11770cad1c18645d07
web diff http://tartarus.org/~simon-git/gitweb/?p=putty.git;a=commitdiff;h=3c912e799430a3803d46dc11770cad1c18645d07;hp=f750a185873eba65f0fbb95dce204b0941f3cc25
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Aug 15 21:07:35 2015 +0100

    Withdraw the horrible bodge in make_mouse_ptr().

    We were previously building our own mouse pointers out of pixmaps,
    having first drawn characters from the X server standard font 'cursor'
    on to those pixmaps, giving an effect almost exactly the same as just
    calling gdk_cursor_new(some constant) except that we got to choose the
    foreground and background colours of the resulting pointers.

    But it's not clear why we needed to do that! In both GTK1 and GTK2 as
    of my current testing, the standard colours appear to be just what I
    wanted anyway (white pointer with black outline). The previous
    implementation (and commit comment) was written in 2002, so perhaps it
    was working around a GTK1 bug of the time.

    So I've removed it completely, and replaced it with simple calls to
    gdk_cursor_new  (plus a workaround for GTK1's lack of GDK_BLANK_CURSOR,
    but that's still much simpler than the previous code). If anyone does
    report a colour problem, I may have to go back to doing something
    clever, but if I can possibly arrange it, I'll want to do it by some
    other technique, probably (as suggested in a comment in the previous
    implementation) getting the underlying X cursor id and calling
    XRecolorCursor.

 unix/gtkwin.c |  110 +++++++++++----------------------------------------------
 1 file changed, 20 insertions(+), 90 deletions(-)