aboutsummaryrefslogtreecommitdiff
path: root/map.c
diff options
context:
space:
mode:
authorSimon Tatham <anakin@pobox.com>2020-04-07 06:50:20 +0100
committerSimon Tatham <anakin@pobox.com>2020-04-07 08:59:46 +0100
commit97a0dc0fee0b9e7d1cd488309e03a19e942d1a57 (patch)
treeaf52e6a95d201b578d44bfdeb3d5da5bd87b1c20 /map.c
parentd71ac73d8a4397c35b21ec08388a1c6f94691b64 (diff)
downloadpuzzles-97a0dc0fee0b9e7d1cd488309e03a19e942d1a57.zip
puzzles-97a0dc0fee0b9e7d1cd488309e03a19e942d1a57.tar.gz
puzzles-97a0dc0fee0b9e7d1cd488309e03a19e942d1a57.tar.bz2
puzzles-97a0dc0fee0b9e7d1cd488309e03a19e942d1a57.tar.xz
GTK 3: handle nontrivial window scale factors.
A user pointed out that if you run a GTK 3 puzzles with "GDK_SCALE=2" in the environment, the main game drawing area is blurred. That's because we're choosing the size of our backing Cairo surface based on the number of _logical_ pixels in the window size, not taking into account the fact that the non-unit scale factor means the number of physical pixels is larger. Everything 'works' in the basis - Cairo happily expands the smaller backing surface into the larger window - but resolution is lost in the process. Now we detect the window's scale factor, construct the backing surface appropriately, and compensate for that scaling when drawing to the surface and when blitting the surface to the window.
Diffstat (limited to 'map.c')
0 files changed, 0 insertions, 0 deletions