bug#20432: GDK_SCALE=2 GDK_DPI_SCALE=0.5 destroys GTK+ 3 scroll bar

bug#20432: GDK_SCALE=2 GDK_DPI_SCALE=0.5 destroys GTK+ 3 scroll bar

[Felix E. Klee]

I'm running Emacs on high DPI screen, and for scaling icons and other UI
elements in GTK+ applications, I've set in the environment:

    GDK_SCALE=2
    GDK_DPI_SCALE=0.5

This, however, confuses EMACS: The scrollbar gets squished.



In GNU Emacs 24.5.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.2)
 of 2015-04-20 on bitzer.hoetzel.info
Windowing system distributor `The X.Org Foundation', version 11.0.11701000
System Description: Arch Linux

Configured using:
 `configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --with-x-toolkit=gtk3 --with-xft
 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong
 --param=ssp-buffer-size=4' CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro'

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...
Quit
Making completion list...
Quit
scroll-up-command: End of buffer

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message idna format-spec
rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns mail-prsvr mail-utils help-mode easymenu time-date
tooltip electric uniquify ediff-hook vc-hooks lisp-float-type mwheel
x-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list
newcomment lisp-mode prog-mode register page menu-bar rfn-eshadow timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer nadvice loaddefs button faces cus-face macroexp
files text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

Memory information:
((conses 16 74597 8753)
 (symbols 48 17662 0)
 (miscs 40 64 138)
 (strings 32 9283 4419)
 (string-bytes 1 253558)
 (vectors 16 8988)
 (vector-slots 8 384078 17367)
 (floats 8 64 222)
 (intervals 56 183 16)
 (buffers 960 13)
 (heap 1024 24992 889))

bug#20432: Further information (plus 1/2 workaround)

[Felix E. Klee]

See also discussion in Arch Linux Forums:
<https://bbs.archlinux.org/viewtopic.php?pid=1523352#p1523352>

bug#20432: GDK_SCALE=2 GDK_DPI_SCALE=0.5 destroys GTK+ 3 scroll bar

[Jan Djärv]

Hi.

Den 2015-04-26 12:01, Felix E. Klee skrev:
> I'm running Emacs on high DPI screen, and for scaling icons and other UI
> elements in GTK+ applications, I've set in the environment:
>
>      GDK_SCALE=2
>      GDK_DPI_SCALE=0.5
>
> This, however, confuses EMACS: The scrollbar gets squished.

This GTK feature is very poorly designed.  We can not support it correctly, as 
we don't use Gtk+ exclusively.  There is a race between Gtk+ and the window 
manager and Emacs that will result in different frame sizes on frame creation. 
  Sometimes its the default size (80x34), sometimes its twice as big.

Also, the Gtk+ code blindly multiplies anything with GTK_SCALE.  So for 
example, given GTK_SCALE=2, if we have font size 15, it becomes 30.  But in 
order to compensate for this multiplication we need to divide with 2 before 
passing sizes to Gtk+.  So 15 becomes 7 (integer division), which Gtk+ turns 
to 14.  So there will be glitches, live with it.

But at least we draw things correctly in the trunk now.

	Jan D.

>
>
>
> In GNU Emacs 24.5.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.2)
>   of 2015-04-20 on bitzer.hoetzel.info
> Windowing system distributor `The X.Org Foundation', version 11.0.11701000
> System Description: Arch Linux
>
> Configured using:
>   `configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
>   --localstatedir=/var --with-x-toolkit=gtk3 --with-xft
>   'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong
>   --param=ssp-buffer-size=4' CPPFLAGS=-D_FORTIFY_SOURCE=2
>   LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro'
>
> Important settings:
>    value of $LANG: en_US.UTF-8
>    locale-coding-system: utf-8-unix
>
> Major mode: Fundamental
>
> Minor modes in effect:
>    tooltip-mode: t
>    electric-indent-mode: t
>    mouse-wheel-mode: t
>    tool-bar-mode: t
>    menu-bar-mode: t
>    file-name-shadow-mode: t
>    global-font-lock-mode: t
>    blink-cursor-mode: t
>    auto-composition-mode: t
>    auto-encryption-mode: t
>    auto-compression-mode: t
>    buffer-read-only: t
>    line-number-mode: t
>    transient-mark-mode: t
>
> Recent messages:
> For information about GNU Emacs and the GNU system, type C-h C-a.
> Making completion list...
> Quit
> Making completion list...
> Quit
> scroll-up-command: End of buffer
>
> Load-path shadows:
> None found.
>
> Features:
> (shadow sort gnus-util mail-extr emacsbug message idna format-spec
> rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
> mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
> mm-util help-fns mail-prsvr mail-utils help-mode easymenu time-date
> tooltip electric uniquify ediff-hook vc-hooks lisp-float-type mwheel
> x-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list
> newcomment lisp-mode prog-mode register page menu-bar rfn-eshadow timer
> select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
> frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai
> tai-viet lao korean japanese hebrew greek romanian slovak czech european
> ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help
> simple abbrev minibuffer nadvice loaddefs button faces cus-face macroexp
> files text-properties overlay sha1 md5 base64 format env code-pages mule
> custom widget hashtable-print-readable backquote make-network-process
> dbusbind gfilenotify dynamic-setting system-font-setting
> font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)
>
> Memory information:
> ((conses 16 74597 8753)
>   (symbols 48 17662 0)
>   (miscs 40 64 138)
>   (strings 32 9283 4419)
>   (string-bytes 1 253558)
>   (vectors 16 8988)
>   (vector-slots 8 384078 17367)
>   (floats 8 64 222)
>   (intervals 56 183 16)
>   (buffers 960 13)
>   (heap 1024 24992 889))
>
>

bug#20432: GDK_SCALE=2 GDK_DPI_SCALE=0.5 destroys GTK+ 3 scroll bar

[Felix E. Klee]

On Thu, May 14, 2015 at 12:34 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
> This GTK feature is very poorly designed.

HiDPI scaling works beautifully in various other GTK+ 3 applications.

> We can not support it correctly, as we don't use Gtk+ exclusively.

Thanks for the explanation.

> Also, the Gtk+ code blindly multiplies anything with GTK_SCALE. So for
> example, given GTK_SCALE=2, if we have font size 15, it becomes 30.

That is what `GDK_DPI_SCALE` is for. Example:

    export GDK_SCALE=2
    export GDK_DPI_SCALE=0.5

> So there will be glitches, live with it.

It’s not for me. I set up a HiDPI machine for a friend who’s turning
eighty this year. While he has great vision given his age, some UI
elements are just too small without scaling. They are barely visible.

This is a big issue, not something that should be ignored. Get access to
a HiDPI screen, and you’ll see what I mean.

> But at least we draw things correctly in the trunk now.

Great!

bug#20432: GDK_SCALE=2 GDK_DPI_SCALE=0.5 destroys GTK+ 3 scroll bar

[Jan Djärv]

Den 2015-05-14 13:59, Felix E. Klee skrev:
> On Thu, May 14, 2015 at 12:34 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>> This GTK feature is very poorly designed.
>
> HiDPI scaling works beautifully in various other GTK+ 3 applications.

I'm sure it does, but the world is bigger than Gtk+ 3.

>
>> We can not support it correctly, as we don't use Gtk+ exclusively.
>
> Thanks for the explanation.
>
>> Also, the Gtk+ code blindly multiplies anything with GTK_SCALE. So for
>> example, given GTK_SCALE=2, if we have font size 15, it becomes 30.
>
> That is what `GDK_DPI_SCALE` is for. Example:
>
>      export GDK_SCALE=2
>      export GDK_DPI_SCALE=0.5

That does not help.  For WM hints, Gtk+ uses GDK_SCALE. GDK_DPI_SCALE is only 
used for scaling Xft fonts.  Anyway, multiplying with 0.5 or divide by 2 is 
the same for integer arithmetics.

An alternative would be for Emacs to multply font sizes with GDK_SCALE.
I think that might be tricky, but I will check.

>
>> So there will be glitches, live with it.
>
> It’s not for me. I set up a HiDPI machine for a friend who’s turning
> eighty this year. While he has great vision given his age, some UI
> elements are just too small without scaling. They are barely visible.
>
> This is a big issue, not something that should be ignored. Get access to
> a HiDPI screen, and you’ll see what I mean.

I have three already.

	Jan D.

bug#20432: GDK_SCALE=2 GDK_DPI_SCALE=0.5 destroys GTK+ 3 scroll bar

[Felix E. Klee]

On Thu, May 14, 2015 at 1:33 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>> That is what `GDK_DPI_SCALE` is for. Example:
>>
>>      export GDK_SCALE=2
>>      export GDK_DPI_SCALE=0.5
>
> That does not help. For WM hints, Gtk+ uses GDK_SCALE.

OK. BTW on the system I’ve set up I position and resize windows with the
WM (FVWM), and there are no issues with `GDK_SCALE`. If I specify that a
window should be sized 2000 × 1000 px, then it’s set to that size.
`GDK_SCALE` only affects the contents of the window.

> Anyway, multiplying with 0.5 or divide by 2 is the same for integer
> arithmetics.

0.5 is not an integer. ;-)

> An alternative would be for Emacs to multply font sizes with
> GDK_SCALE.

Why bother? Don’t fonts get rendered via the GTK+ API?

bug#20432: GDK_SCALE=2 GDK_DPI_SCALE=0.5 destroys GTK+ 3 scroll bar

[Jan Djärv]

Den 2015-05-14 14:46, Felix E. Klee skrev:
> On Thu, May 14, 2015 at 1:33 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>>> That is what `GDK_DPI_SCALE` is for. Example:
>>>
>>>       export GDK_SCALE=2
>>>       export GDK_DPI_SCALE=0.5
>>
>> That does not help. For WM hints, Gtk+ uses GDK_SCALE.
>
> OK. BTW on the system I’ve set up I position and resize windows with the
> WM (FVWM), and there are no issues with `GDK_SCALE`. If I specify that a
> window should be sized 2000 × 1000 px, then it’s set to that size.
> `GDK_SCALE` only affects the contents of the window.

That is true, and part of why this is a half-baked solution.
xrandr --scale works fine for me, no need to fiddle with per application 
settings.  Also, it works fine to plug in a non-hidpi monitor and move apps 
from one monitor to another.  GDK_SCALE absolutely breaks that.

>
>> An alternative would be for Emacs to multply font sizes with
>> GDK_SCALE.
>
> Why bother? Don’t fonts get rendered via the GTK+ API?

Gtk+ is only used for the tool bar, menus and scroll bar (more or less).
Gtk+ is not a requirement for Emacs.
Anyway, its a lot of work.  A lot of Emacs internals needs to know the font 
size and the scaling needs to be applied in many places.

	Jan D.

bug#20432: GDK_SCALE=2 GDK_DPI_SCALE=0.5 destroys GTK+ 3 scroll bar

[Felix E. Klee]

On Thu, May 14, 2015 at 2:13 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
> xrandr --scale works fine for me, no need to fiddle with per
> application settings.

Well, that’s what I call a half-baked solution: It means you turn your
screen into a standard-DPI one. For scaling old apps, I wrote Vncdesk:

<https://github.com/feklee/vncdesk>

Another option to make EMACS compatible with HiDPI could be to use a
high resolution icon theme. At the moment, I’ve set `GDK_SCALE=1`, and I
scale the toolbar:

<https://bbs.archlinux.org/viewtopic.php?pid=1523352#p1523352>

I assume other elements can also be scaled. Almost invisible at the
moment are for example checkboxes in `customize`.

bug#20432: GDK_SCALE=2 GDK_DPI_SCALE=0.5 destroys GTK+ 3 scroll bar

[Paul Eggert]

Thanks, Jan D., for looking into the problem.  It does appear to be a 
mess.  In theory I suppose Emacs should use 
gdk_screen_get_monitor_scale_factor to get the monitor scale factor; but 
in practice the situation is so messed up (and a lot of work would be 
needed to fix it) that it might not be worth bothering.

By the way, on my Fedora 21 x86-64 host, setting GDK_SCALE=2 
GDK_DPI_SCALE=0.5 has no effect on emacs -Q, even with the recent 
fixes.  Perhaps this is due to the races you mentioned?

I installed a minor followup patch to catch some integer overflows (I 
realize GTK+ can crash in those cases and that other integer overflows 
are possible in Emacs, but one thing at a time....).

bug#20432: GDK_SCALE=2 GDK_DPI_SCALE=0.5 destroys GTK+ 3 scroll bar

[Jan D.]

Paul Eggert skrev den 2015-05-14 18:38:
> Thanks, Jan D., for looking into the problem.  It does appear to be a
> mess.  In theory I suppose Emacs should use
> gdk_screen_get_monitor_scale_factor to get the monitor scale factor; but
> in practice the situation is so messed up (and a lot of work would be
> needed to fix it) that it might not be worth bothering.
>
> By the way, on my Fedora 21 x86-64 host, setting GDK_SCALE=2
> GDK_DPI_SCALE=0.5 has no effect on emacs -Q, even with the recent
> fixes.  Perhaps this is due to the races you mentioned?

No, that just affects the initial frame size.
You should see an effect on toolbar and scroll bar size (they should be 
twice as big).  Are you compiling with Gtk+ 3.8 or later?

	Jan D.

bug#20432: GDK_SCALE=2 GDK_DPI_SCALE=0.5 destroys GTK+ 3 scroll bar

[Paul Eggert]

Jan D. wrote:
>> By the way, on my Fedora 21 x86-64 host, setting GDK_SCALE=2
>> GDK_DPI_SCALE=0.5 has no effect on emacs -Q, even with the recent
>> fixes.  Perhaps this is due to the races you mentioned?
>
> No, that just affects the initial frame size.
> You should see an effect on toolbar and scroll bar size (they should be twice as
> big).

Yes, you're right, it works.  I had misconfigured my Emacs (configured with the 
Lucid toolkit).  Sorry about the confusion.

I suppose I should mention that when I tried a properly-configured Emacs with 
GDK_SCALE=2 it dumped core for me.  I was running on Fedora 21 x86-64 (which has 
gtk3-3.14.13-1.fc21.x86_64) and displaying over the Internet to Ubuntu 15.04.  I 
can't reproduce the problem so it could be a timing thing.  The core dump occurs 
within gtk_window_get_size, which is called by xg_frame_set_char_size.   I 
wasn't running under a debugger, so I got only this backtrace:

> $ GDK_SCALE=2 src/emacs -Q
> X protocol error: BadAccess (attempt to access private resource denied) on protocol request 130
> When compiled with GTK, Emacs cannot recover from X disconnects.
> This is a GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=85715
> For details, see etc/PROBLEMS.
> Fatal error 6: Aborted
> Backtrace:
> src/emacs[0x503bc2]
> src/emacs[0x4ebb09]
> src/emacs[0x503c53]
> src/emacs[0x4be78e]
> src/emacs[0x4c2a28]
> src/emacs[0x4c2a8d]
> /lib64/libX11.so.6(_XError+0x11d)[0x7f0edfd1d4dd]
> /lib64/libX11.so.6(+0x42427)[0x7f0edfd1a427]
> /lib64/libX11.so.6(+0x424e5)[0x7f0edfd1a4e5]
> /lib64/libX11.so.6(_XReply+0x230)[0x7f0edfd1b490]
> /lib64/libX11.so.6(XGetGeometry+0x8e)[0x7f0edfcffd9e]
> /lib64/libgdk-3.so.0(+0x5d37f)[0x7f0ee1b7537f]
> /lib64/libgdk-3.so.0(gdk_window_get_geometry+0x104)[0x7f0ee1b4e014]
> /lib64/libgdk-3.so.0(gdk_screen_get_monitor_at_window+0x8f)[0x7f0ee1b4974f]
> /lib64/libgtk-3.so.0(+0x332d79)[0x7f0ee2104d79]
> /lib64/libgtk-3.so.0(+0x3367fb)[0x7f0ee21087fb]
> /lib64/libgtk-3.so.0(gtk_window_get_size+0xab)[0x7f0ee210e88b]
> src/emacs[0x4ddff8]
> src/emacs[0x4c94fa]
> src/emacs[0x4273b0]
> src/emacs[0x4d2829]
> src/emacs[0x55bb33]
> src/emacs[0x58ecb3]
> src/emacs[0x55b57f]
> src/emacs[0x55b94b]
> src/emacs[0x58ecb3]
> src/emacs[0x55b94b]
> src/emacs[0x58ecb3]
> src/emacs[0x55b94b]
> src/emacs[0x58ecb3]
> src/emacs[0x55b94b]
> src/emacs[0x58ecb3]
> src/emacs[0x55aa08]
> src/emacs[0x55ad0b]
> src/emacs[0x55e2d1]
> src/emacs[0x55a107]
> src/emacs[0x4ee8ac]
> src/emacs[0x559fe3]
> src/emacs[0x4ebf08]
> src/emacs[0x4f04bb]
> src/emacs[0x4f0808]
> ...
> Aborted (core dumped)


Addrline converts this to:

emacs_backtrace at /home/eggert/src/gnu/emacs/static-checking/src/sysdep.c:2188
terminate_due_to_signal at 
/home/eggert/src/gnu/emacs/static-checking/src/emacs.c:374
emacs_abort at /home/eggert/src/gnu/emacs/static-checking/src/sysdep.c:2201
x_connection_closed at /home/eggert/src/gnu/emacs/static-checking/src/xterm.c:8525
x_error_quitter at /home/eggert/src/gnu/emacs/static-checking/src/xterm.c:8617
x_error_handler at /home/eggert/src/gnu/emacs/static-checking/src/xterm.c:8588
?? ??:0
?? ??:0
?? ??:0
?? ??:0
?? ??:0
?? ??:0
?? ??:0
?? ??:0
?? ??:0
?? ??:0
?? ??:0
xg_clear_under_internal_border at 
/home/eggert/src/gnu/emacs/static-checking/src/gtkutil.c:848
  (inlined by) xg_frame_set_char_size at 
/home/eggert/src/gnu/emacs/static-checking/src/gtkutil.c:947
x_set_window_size at /home/eggert/src/gnu/emacs/static-checking/src/xterm.c:9729
adjust_frame_size at /home/eggert/src/gnu/emacs/static-checking/src/frame.c:491 
(discriminator 8)
Fx_create_frame at /home/eggert/src/gnu/emacs/static-checking/src/xfns.c:3305
Ffuncall at /home/eggert/src/gnu/emacs/static-checking/src/eval.c:2719
exec_byte_code at /home/eggert/src/gnu/emacs/static-checking/src/bytecode.c:919
funcall_lambda at /home/eggert/src/gnu/emacs/static-checking/src/eval.c:2957
backtrace_debug_on_exit at /home/eggert/src/gnu/emacs/static-checking/src/eval.c:159
  (inlined by) Ffuncall at 
/home/eggert/src/gnu/emacs/static-checking/src/eval.c:2791
exec_byte_code at /home/eggert/src/gnu/emacs/static-checking/src/bytecode.c:919
backtrace_debug_on_exit at /home/eggert/src/gnu/emacs/static-checking/src/eval.c:159
  (inlined by) Ffuncall at 
/home/eggert/src/gnu/emacs/static-checking/src/eval.c:2791
exec_byte_code at /home/eggert/src/gnu/emacs/static-checking/src/bytecode.c:919
backtrace_debug_on_exit at /home/eggert/src/gnu/emacs/static-checking/src/eval.c:159
  (inlined by) Ffuncall at 
/home/eggert/src/gnu/emacs/static-checking/src/eval.c:2791
exec_byte_code at /home/eggert/src/gnu/emacs/static-checking/src/bytecode.c:919
backtrace_debug_on_exit at /home/eggert/src/gnu/emacs/static-checking/src/eval.c:159
  (inlined by) Ffuncall at 
/home/eggert/src/gnu/emacs/static-checking/src/eval.c:2791
exec_byte_code at /home/eggert/src/gnu/emacs/static-checking/src/bytecode.c:919
apply_lambda at /home/eggert/src/gnu/emacs/static-checking/src/eval.c:2829
eval_sub at /home/eggert/src/gnu/emacs/static-checking/src/eval.c:2256
Feval at /home/eggert/src/gnu/emacs/static-checking/src/eval.c:1997 
(discriminator 3)
internal_condition_case at 
/home/eggert/src/gnu/emacs/static-checking/src/eval.c:1350
top_level_1 at /home/eggert/src/gnu/emacs/static-checking/src/keyboard.c:1162
internal_catch at /home/eggert/src/gnu/emacs/static-checking/src/eval.c:1110
command_loop at /home/eggert/src/gnu/emacs/static-checking/src/keyboard.c:1118
recursive_edit_1 at /home/eggert/src/gnu/emacs/static-checking/src/keyboard.c:729
Frecursive_edit at /home/eggert/src/gnu/emacs/static-checking/src/keyboard.c:800

bug#20432: GDK_SCALE=2 GDK_DPI_SCALE=0.5 destroys GTK+ 3 scroll bar

[Jan D.]

Hi.

Looks like you had an X protocol error.  Its possible we haven’t covered all cases for GDK_SCALE yet.

	Jan D.

> 15 maj 2015 kl. 04:59 skrev Paul Eggert <eggert@cs.ucla.edu>:
> 
> Jan D. wrote:
>>> By the way, on my Fedora 21 x86-64 host, setting GDK_SCALE=2
>>> GDK_DPI_SCALE=0.5 has no effect on emacs -Q, even with the recent
>>> fixes.  Perhaps this is due to the races you mentioned?
>> 
>> No, that just affects the initial frame size.
>> You should see an effect on toolbar and scroll bar size (they should be twice as
>> big).
> 
> Yes, you're right, it works.  I had misconfigured my Emacs (configured with the Lucid toolkit).  Sorry about the confusion.
> 
> I suppose I should mention that when I tried a properly-configured Emacs with GDK_SCALE=2 it dumped core for me.  I was running on Fedora 21 x86-64 (which has gtk3-3.14.13-1.fc21.x86_64) and displaying over the Internet to Ubuntu 15.04.  I can't reproduce the problem so it could be a timing thing.  The core dump occurs within gtk_window_get_size, which is called by xg_frame_set_char_size.   I wasn't running under a debugger, so I got only this backtrace:
> 
>> $ GDK_SCALE=2 src/emacs -Q
>> X protocol error: BadAccess (attempt to access private resource denied) on protocol request 130
>> When compiled with GTK, Emacs cannot recover from X disconnects.
>> This is a GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=85715
>> For details, see etc/PROBLEMS.
>> Fatal error 6: Aborted
>> Backtrace:
>> src/emacs[0x503bc2]
>> src/emacs[0x4ebb09]
>> src/emacs[0x503c53]
>> src/emacs[0x4be78e]
>> src/emacs[0x4c2a28]
>> src/emacs[0x4c2a8d]
>> /lib64/libX11.so.6(_XError+0x11d)[0x7f0edfd1d4dd]
>> /lib64/libX11.so.6(+0x42427)[0x7f0edfd1a427]
>> /lib64/libX11.so.6(+0x424e5)[0x7f0edfd1a4e5]
>> /lib64/libX11.so.6(_XReply+0x230)[0x7f0edfd1b490]
>> /lib64/libX11.so.6(XGetGeometry+0x8e)[0x7f0edfcffd9e]
>> /lib64/libgdk-3.so.0(+0x5d37f)[0x7f0ee1b7537f]
>> /lib64/libgdk-3.so.0(gdk_window_get_geometry+0x104)[0x7f0ee1b4e014]
>> /lib64/libgdk-3.so.0(gdk_screen_get_monitor_at_window+0x8f)[0x7f0ee1b4974f]
>> /lib64/libgtk-3.so.0(+0x332d79)[0x7f0ee2104d79]
>> /lib64/libgtk-3.so.0(+0x3367fb)[0x7f0ee21087fb]
>> /lib64/libgtk-3.so.0(gtk_window_get_size+0xab)[0x7f0ee210e88b]
>> src/emacs[0x4ddff8]
>> src/emacs[0x4c94fa]
>> src/emacs[0x4273b0]
>> src/emacs[0x4d2829]
>> src/emacs[0x55bb33]
>> src/emacs[0x58ecb3]
>> src/emacs[0x55b57f]
>> src/emacs[0x55b94b]
>> src/emacs[0x58ecb3]
>> src/emacs[0x55b94b]
>> src/emacs[0x58ecb3]
>> src/emacs[0x55b94b]
>> src/emacs[0x58ecb3]
>> src/emacs[0x55b94b]
>> src/emacs[0x58ecb3]
>> src/emacs[0x55aa08]
>> src/emacs[0x55ad0b]
>> src/emacs[0x55e2d1]
>> src/emacs[0x55a107]
>> src/emacs[0x4ee8ac]
>> src/emacs[0x559fe3]
>> src/emacs[0x4ebf08]
>> src/emacs[0x4f04bb]
>> src/emacs[0x4f0808]
>> ...
>> Aborted (core dumped)
> 
> 
> Addrline converts this to:
> 
> emacs_backtrace at /home/eggert/src/gnu/emacs/static-checking/src/sysdep.c:2188
> terminate_due_to_signal at /home/eggert/src/gnu/emacs/static-checking/src/emacs.c:374
> emacs_abort at /home/eggert/src/gnu/emacs/static-checking/src/sysdep.c:2201
> x_connection_closed at /home/eggert/src/gnu/emacs/static-checking/src/xterm.c:8525
> x_error_quitter at /home/eggert/src/gnu/emacs/static-checking/src/xterm.c:8617
> x_error_handler at /home/eggert/src/gnu/emacs/static-checking/src/xterm.c:8588
> ?? ??:0
> ?? ??:0
> ?? ??:0
> ?? ??:0
> ?? ??:0
> ?? ??:0
> ?? ??:0
> ?? ??:0
> ?? ??:0
> ?? ??:0
> ?? ??:0
> xg_clear_under_internal_border at /home/eggert/src/gnu/emacs/static-checking/src/gtkutil.c:848
> (inlined by) xg_frame_set_char_size at /home/eggert/src/gnu/emacs/static-checking/src/gtkutil.c:947
> x_set_window_size at /home/eggert/src/gnu/emacs/static-checking/src/xterm.c:9729
> adjust_frame_size at /home/eggert/src/gnu/emacs/static-checking/src/frame.c:491 (discriminator 8)
> Fx_create_frame at /home/eggert/src/gnu/emacs/static-checking/src/xfns.c:3305
> Ffuncall at /home/eggert/src/gnu/emacs/static-checking/src/eval.c:2719
> exec_byte_code at /home/eggert/src/gnu/emacs/static-checking/src/bytecode.c:919
> funcall_lambda at /home/eggert/src/gnu/emacs/static-checking/src/eval.c:2957
> backtrace_debug_on_exit at /home/eggert/src/gnu/emacs/static-checking/src/eval.c:159
> (inlined by) Ffuncall at /home/eggert/src/gnu/emacs/static-checking/src/eval.c:2791
> exec_byte_code at /home/eggert/src/gnu/emacs/static-checking/src/bytecode.c:919
> backtrace_debug_on_exit at /home/eggert/src/gnu/emacs/static-checking/src/eval.c:159
> (inlined by) Ffuncall at /home/eggert/src/gnu/emacs/static-checking/src/eval.c:2791
> exec_byte_code at /home/eggert/src/gnu/emacs/static-checking/src/bytecode.c:919
> backtrace_debug_on_exit at /home/eggert/src/gnu/emacs/static-checking/src/eval.c:159
> (inlined by) Ffuncall at /home/eggert/src/gnu/emacs/static-checking/src/eval.c:2791
> exec_byte_code at /home/eggert/src/gnu/emacs/static-checking/src/bytecode.c:919
> backtrace_debug_on_exit at /home/eggert/src/gnu/emacs/static-checking/src/eval.c:159
> (inlined by) Ffuncall at /home/eggert/src/gnu/emacs/static-checking/src/eval.c:2791
> exec_byte_code at /home/eggert/src/gnu/emacs/static-checking/src/bytecode.c:919
> apply_lambda at /home/eggert/src/gnu/emacs/static-checking/src/eval.c:2829
> eval_sub at /home/eggert/src/gnu/emacs/static-checking/src/eval.c:2256
> Feval at /home/eggert/src/gnu/emacs/static-checking/src/eval.c:1997 (discriminator 3)
> internal_condition_case at /home/eggert/src/gnu/emacs/static-checking/src/eval.c:1350
> top_level_1 at /home/eggert/src/gnu/emacs/static-checking/src/keyboard.c:1162
> internal_catch at /home/eggert/src/gnu/emacs/static-checking/src/eval.c:1110
> command_loop at /home/eggert/src/gnu/emacs/static-checking/src/keyboard.c:1118
> recursive_edit_1 at /home/eggert/src/gnu/emacs/static-checking/src/keyboard.c:729
> Frecursive_edit at /home/eggert/src/gnu/emacs/static-checking/src/keyboard.c:800