bug#23925: 25.0.95; display broken when maximizing frame

bug#23925: 25.0.95; display broken when maximizing frame

[Roland Winkler]

After a long time I build again a more recent emacs.  Unfortunately
it gives me a rather unpleasant experience when maximizing the emacs
frame (using the maximize function of the xfce window manager):
somehow the frame is not redrawn properly, emacs seems to be unaware
of the new frame size and the minibuffer disappears completely.
Instead the desktop background is displayed in large parts of the
emacs frame.  Unmaximizing makes the problem go away.  But obviously
that is no solution.  I can provide more details if you let me know
what would be interesting.




In GNU Emacs 25.0.95.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.18.9, cairo version 1.14.6)
 of 2016-07-08 built on regnitz
Windowing system distributor 'The X.Org Foundation', version 11.0.11803000
System Description:	Ubuntu 16.04 LTS

Configured using:
 'configure --with-xwidgets --with-x-toolkit=gtk3 --with-cairo'

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO IMAGEMAGICK SOUND GPM DBUS GCONF
GSETTINGS NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT
LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XWIDGETS

Important settings:
  value of $LC_COLLATE: C
  value of $LANG: en_US.utf8
  value of $XMODIFIERS: 
  locale-coding-system: utf-8-unix

bug#23925: 25.0.95; display broken when maximizing frame

[Eli Zaretskii]

> Date: Fri, 8 Jul 2016 22:02:23 -0500
> From: "Roland Winkler" <winkler@gnu.org>
> 
> 
> After a long time I build again a more recent emacs.  Unfortunately
> it gives me a rather unpleasant experience when maximizing the emacs
> frame (using the maximize function of the xfce window manager):
> somehow the frame is not redrawn properly, emacs seems to be unaware
> of the new frame size and the minibuffer disappears completely.
> Instead the desktop background is displayed in large parts of the
> emacs frame.  Unmaximizing makes the problem go away.  But obviously
> that is no solution.  I can provide more details if you let me know
> what would be interesting.

Yes, please provide more details.  We are very interested, as we are
close to releasing Emacs 25.1, of which 25.0.95 is the latest
pretest.  What you told so far is disturbing, but doesn't give any
clues where to look for the root cause of the trouble.  I don't think
we've heard such reports in a long, long time.

> Configured using:
>  'configure --with-xwidgets --with-x-toolkit=gtk3 --with-cairo'

One idea I do have is to build without --with-cairo, and see if the
problem goes away.  The Cairo back-end is still experimental, and we
know of several problems with it.

Thanks.

bug#23925: 25.0.95; display broken when maximizing frame

[Clément Pit--Claudel]

[-- Attachment #1.1.1: Type: text/plain, Size: 3053 bytes --]

On 2016-07-09 09:11, Eli Zaretskii wrote:
>> Date: Fri, 8 Jul 2016 22:02:23 -0500
>> From: "Roland Winkler" <winkler@gnu.org>
>>
>>
>> After a long time I build again a more recent emacs.  Unfortunately
>> it gives me a rather unpleasant experience when maximizing the emacs
>> frame (using the maximize function of the xfce window manager):
>> somehow the frame is not redrawn properly, emacs seems to be unaware
>> of the new frame size and the minibuffer disappears completely.
>> Instead the desktop background is displayed in large parts of the
>> emacs frame.  Unmaximizing makes the problem go away.  But obviously
>> that is no solution.  I can provide more details if you let me know
>> what would be interesting.
> 
> Yes, please provide more details.  We are very interested, as we are
> close to releasing Emacs 25.1, of which 25.0.95 is the latest
> pretest.  What you told so far is disturbing, but doesn't give any
> clues where to look for the root cause of the trouble.  I don't think
> we've heard such reports in a long, long time.

Hi Eli and Roland,

I can reproduce this.  I don't usually build with Cairo, but I just did, and the problem does happen here as well.

Some small notes:

- Resizing the frames using the handles works fine
- Maximizing the frame causes the maximized region to not be redisplayed
- Running the following on a non-maximized frame) also causes a display glitch:
    (set-face-attribute 'default nil :height 150)
  (when the frame extends to accommodate the larger font size, the newly added areas do not get redisplayed)
- I have attached a two screenshots showing how the maximized frame looks. The top left (corresponding to the previous size) is properly updated, while the rest of the frame displays what was on the screen when the frame was maximized
- Not sure if it's related or if it should be another bug: font anti-aliasing is not the same when when maximized and unmaximized (see screenshots).

Here is the output of the commands that martin suggested:

(display-monitor-attributes-list)
=> (((name . "DP-2") (geometry 0 0 1920 1080) (workarea 0 0 1920 1055) (mm-size 344 193) (frames #<frame **scratch* 0x12bb5a0>) (source . "Gdk")))

(frame-geometry)
=> ((outer-position 0 . 0) (outer-size 1920 . 1055) (external-border-size 0 . 1) (title-bar-size 0 . 23) (menu-bar-external . t) (menu-bar-size 0 . 0) (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 0 . 0) (internal-border-width . 0))

(setq frame-size-history '(5))
=> (5)

(frame--size-history)
=> nil

(In other buffer:)
Frame size history of #<frame **scratch* 0x12bb5a0>
x-handle-net-wm-state    nil (nil nil)

My version info:

In GNU Emacs 25.1.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8, cairo version 1.13.1)
 of 2016-06-26 built on clem-w50-mint
Repository revision: 431437b6593320dc5a7a8aac9c911c778a656117
Windowing system distributor 'The X.Org Foundation', version 11.0.11501000
System Description:	Linux Mint 17.3 Rosa

Cheers,
Clément

[-- Attachment #1.1.2: Screenshot from 2016-07-09 11:35:30.png --]
[-- Type: image/png, Size: 225731 bytes --]

[-- Attachment #1.1.3: Screenshot from 2016-07-09 11:40:28.png --]
[-- Type: image/png, Size: 242687 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

bug#23925: 25.0.95; display broken when maximizing frame

[martin rudalics]

 > I can reproduce this.  I don't usually build with Cairo, but I just did, and the problem does happen here as well.

But you can't reproduce the problem without Cairo.  Correct?

 > (frame-geometry)
 > => ((outer-position 0 . 0) (outer-size 1920 . 1055) (external-border-size 0 . 1) (title-bar-size 0 . 23) (menu-bar-external . t) (menu-bar-size 0 . 0) (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 0 . 0) (internal-border-width . 0))

In this state please also evaluate

(window--dump-frame)

and post the contents of buffer *window-frame-dump*.

Thanks, martin

bug#23925: 25.0.95; display broken when maximizing frame

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 1053 bytes --]

On 2016-07-09 17:30, martin rudalics wrote:
> In this state please also evaluate
> 
> (window--dump-frame)

frame pixel: 1920 x 1030   cols/lines: 240 x 64   units: 8 x 16
frame text pixel: 1904 x 1030   cols/lines: 238 x 64
tool: 0  scroll: 0/0  fringe: 16  border: 0  right: 0  bottom: 0

#<window 3 on *scratch*>   parent: nil
pixel left: 0   top: 0   size: 1920 x 1014   new: 669
char left: 0   top: 0   size: 240 x 63   new: 84
normal: 1.0 x 1.0   new: 1.0
body pixel: 1904 x 979   char: 238 x 61
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 0  divider: 0
height header-line: 16  mode-line: 19  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 1014   size: 1920 x 16   new: 0
char left: 0   top: 63   size: 240 x 1   new: 84
normal: 1.0 x 1.0   new: ignore
body pixel: 1904 x 16   char: 238 x 1
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 0  divider: 0




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

bug#23925: 25.0.95; display broken when maximizing frame

[martin rudalics]

Clément:

 > (((name . "DP-2") (geometry 0 0 1920 1080) (workarea 0 0 1920 1055) (mm-size 344 193) (frames #<frame **scratch* 0x12bb5a0>) (source . "Gdk")))

 > ((outer-position 0 . 0) (outer-size 1920 . 1055) (external-border-size 0 . 1) (title-bar-size 0 . 23) (menu-bar-external . t) (menu-bar-size 0 . 0) (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 0 . 0) (internal-border-width . 0))

 > frame pixel: 1920 x 1030   cols/lines: 240 x 64   units: 8 x 16
 > frame text pixel: 1904 x 1030   cols/lines: 238 x 64
 > tool: 0  scroll: 0/0  fringe: 16  border: 0  right: 0  bottom: 0
 >
 > #<window 3 on *scratch*>   parent: nil
 > pixel left: 0   top: 0   size: 1920 x 1014   new: 669
 > char left: 0   top: 0   size: 240 x 63   new: 84
 > normal: 1.0 x 1.0   new: 1.0
 > body pixel: 1904 x 979   char: 238 x 61
 > width left fringe: 8  left margin: 0  right margin: 0
 > width right fringe: 8  scroll-bar: 0  divider: 0
 > height header-line: 16  mode-line: 19  divider: 0
 >
 > #<window 4 on  *Minibuf-0*>   parent: nil
 > pixel left: 0   top: 1014   size: 1920 x 16   new: 0
 > char left: 0   top: 63   size: 240 x 1   new: 84
 > normal: 1.0 x 1.0   new: ignore
 > body pixel: 1904 x 16   char: 238 x 1
 > width left fringe: 8  left margin: 0  right margin: 0
 > width right fringe: 8  scroll-bar: 0  divider: 0
 > height header-line: 0  mode-line: 0  divider: 0


Roland:

 > (((name . "DP2") (geometry 0 0 1920 1080) (workarea 0 25 1920 1055) (mm-size 510 287) (frames #<frame emacs@regnitz 0x1244a90>) (source . "Gdk")))

 > ((outer-position 0 . 25) (outer-size 1913 . 1052) (external-border-size 5 . 5) (title-bar-size 0 . 18) (menu-bar-external . t) (menu-bar-size 1903 . 22) (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 0 . 0) (internal-border-width . 1))

 > frame pixel: 1903 x 1002   cols/lines: 191 x 50   units: 10 x 20
 > frame text pixel: 1870 x 1000   cols/lines: 187 x 50
 > tool: 0  scroll: 15/0  fringe: 16  border: 1  right: 0  bottom: 0
 >
 > #<window 3 on *Messages*>   parent: nil
 > pixel left: 0   top: 0   size: 1901 x 980   new: 820
 > char left: 0   top: 0   size: 190 x 49   new: 38
 > normal: 1.0 x 1.0   new: nil
 > body pixel: 1870 x 960   char: 187 x 48
 > width left fringe: 8  left margin: 0  right margin: 0
 > width right fringe: 8  scroll-bar: 15  divider: 0
 > height header-line: 0  mode-line: 20  divider: 0
 >
 > #<window 4 on  *Minibuf-0*>   parent: nil
 > pixel left: 0   top: 980   size: 1901 x 20   new: 0
 > char left: 0   top: 49   size: 190 x 1   new: 1
 > normal: 1.0 x 1.0   new: 0
 > body pixel: 1870 x 20   char: 187 x 1
 > width left fringe: 8  left margin: 0  right margin: 0
 > width right fringe: 8  scroll-bar: 15  divider: 0
 > height header-line: 0  mode-line: 0  divider: 0


All these values are as expected - I suppose that they are the same as
in a non-cairo GTK session.  What happens when you type F11
(‘toggle-frame-fullscreen’) in a normal frame?  Also, could one of you
try a Lucid or Motif build with cairo and see what happens?

martin

bug#23925: 25.0.95; display broken when maximizing frame

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 1640 bytes --]

On 2016-07-11 11:14, martin rudalics wrote:
> All these values are as expected - I suppose that they are the same as
> in a non-cairo GTK session.  What happens when you type F11
> (‘toggle-frame-fullscreen’) in a normal frame?  Also, could one of you
> try a Lucid or Motif build with cairo and see what happens?

F11 in a non-cairo session works fine; in a cairo one, it shows exactly the same problem.

In a non-cairo build, I get:

((outer-position 0 . 0) (outer-size 1920 . 1055) (external-border-size 0 . 1) (title-bar-size 0 . 23) (menu-bar-external . t) (menu-bar-size 1920 . 22) (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 1920 . 44) (internal-border-width . 0))

frame pixel: 1920 x 964   cols/lines: 240 x 56   units: 8 x 17
frame text pixel: 1891 x 964   cols/lines: 236 x 56
tool: 0  scroll: 13/0  fringe: 16  border: 0  right: 0  bottom: 0

#<window 3 on *scratch*>   parent: nil
pixel left: 0   top: 0   size: 1920 x 930   new: 947
char left: 0   top: 0   size: 240 x 54   new: 54
normal: 1.0 x 1.0   new: nil
body pixel: 1891 x 913   char: 236 x 53
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 13  divider: 0
height header-line: 0  mode-line: 17  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 930   size: 1920 x 34   new: 0
char left: 0   top: 54   size: 240 x 2   new: 1
normal: 1.0 x 1.0   new: 0
body pixel: 1891 x 34   char: 236 x 2
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 13  divider: 0
height header-line: 0  mode-line: 0  divider: 0



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

bug#23925: 25.0.95; display broken when maximizing frame

[martin rudalics]

 > In a non-cairo build, I get:
 >
 > ((outer-position 0 . 0) (outer-size 1920 . 1055) (external-border-size 0 . 1) (title-bar-size 0 . 23) (menu-bar-external . t) (menu-bar-size 1920 . 22) (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 1920 . 44) (internal-border-width . 0))
 >
 > frame pixel: 1920 x 964   cols/lines: 240 x 56   units: 8 x 17
 > frame text pixel: 1891 x 964   cols/lines: 236 x 56
 > tool: 0  scroll: 13/0  fringe: 16  border: 0  right: 0  bottom: 0
 >
 > #<window 3 on *scratch*>   parent: nil
 > pixel left: 0   top: 0   size: 1920 x 930   new: 947
 > char left: 0   top: 0   size: 240 x 54   new: 54
 > normal: 1.0 x 1.0   new: nil
 > body pixel: 1891 x 913   char: 236 x 53
 > width left fringe: 8  left margin: 0  right margin: 0
 > width right fringe: 8  scroll-bar: 13  divider: 0
 > height header-line: 0  mode-line: 17  divider: 0
 >
 > #<window 4 on  *Minibuf-0*>   parent: nil
 > pixel left: 0   top: 930   size: 1920 x 34   new: 0
 > char left: 0   top: 54   size: 240 x 2   new: 1
 > normal: 1.0 x 1.0   new: 0
 > body pixel: 1891 x 34   char: 236 x 2
 > width left fringe: 8  left margin: 0  right margin: 0
 > width right fringe: 8  scroll-bar: 13  divider: 0
 > height header-line: 0  mode-line: 0  divider: 0

Is it on purpose that you used a tool bar, a menu bar, scroll bars and a
different font height in the non-cairo build?  This way the results are
not easily comparable.

Anyway, I meanwhile built with cairo myself.  The GTK build exhibits
more or less the original problem - though sometimes the frame seems to
maximize correctly.  In addition, scroll bar sliders may disappear at
will and resizing the echo area doesn't behave well either.

A Lucid build shows similar symptoms - its scroll bars behave better,
though.

martin

bug#23925: 25.0.95; display broken when maximizing frame

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 277 bytes --]

On 2016-07-12 09:29, martin rudalics wrote:
> Is it on purpose that you used a tool bar, a menu bar, scroll bars and a
> different font height in the non-cairo build?  This way the results are
> not easily comparable.

Ah, sorry. I used emacs -Q for the non-cairo one.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

bug#23925: 25.0.95; display broken when maximizing frame

[Roland Winkler]

On Tue Jul 12 2016 martin rudalics wrote:
> Anyway, I meanwhile built with cairo myself.  The GTK build
> exhibits more or less the original problem - though sometimes the
> frame seems to maximize correctly.  In addition, scroll bar
> sliders may disappear at will and resizing the echo area doesn't
> behave well either.
> 
> A Lucid build shows similar symptoms - its scroll bars behave
> better, though.

In the meanwhile, I have also built the cairo port with lucid and
motif.  In both case emacs shows the same bug as the gtk build.
Again, I can provide more details as needed, though I expect that
you are better off with your own builds.

Roland

bug#23925: 25.0.95; display broken when maximizing frame

[martin rudalics]

 > In the meanwhile, I have also built the cairo port with lucid and
 > motif.  In both case emacs shows the same bug as the gtk build.
 > Again, I can provide more details as needed, though I expect that
 > you are better off with your own builds.

I'm afraid I can't do much about this anyway.  All these builds are
seriously flawed in many aspects.  People should use them _exclusively_
for fixing these flaws.

martin

bug#23925: 25.0.95; display broken when maximizing frame

[Dmitry Gutov]

Hi all,

On 09.07.2016 12:45, Clément Pit--Claudel wrote:

> - Resizing the frames using the handles works fine
> - Maximizing the frame causes the maximized region to not be redisplayed
> - Running the following on a non-maximized frame) also causes a display glitch:
>      (set-face-attribute 'default nil :height 150)
>    (when the frame extends to accommodate the larger font size, the newly added areas do not get redisplayed)
> - I have attached a two screenshots showing how the maximized frame looks. The top left (corresponding to the previous size) is properly updated, while the rest of the frame displays what was on the screen when the frame was maximized
> - Not sure if it's related or if it should be another bug: font anti-aliasing is not the same when when maximized and unmaximized (see screenshots).

I have just tried a --with-cairo build of the latest master, and can't 
repro any of the symptoms described here, as long as Emacs is launched 
with GDK_SCALE=1 (I have a HiDPI screen, and redisplay with scale=2 
looks very broken).

bug#23925: 25.0.95; display broken when maximizing frame

[Dmitry Gutov]

On 22.11.2018 16:12, Dmitry Gutov wrote:

> I have just tried a --with-cairo build of the latest master, and can't 
> repro any of the symptoms described here, as long as Emacs is launched 
> with GDK_SCALE=1 (I have a HiDPI screen, and redisplay with scale=2 
> looks very broken).

And with the current emacs-26 branch, even that is not a problem.

So to sum up, I'm failing to reproduce any of the problems described in 
this bug report. Could any of the previous commenters try?

bug#23925: 25.0.95; display broken when maximizing frame

[Clément Pit-Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 617 bytes --]

On 10/12/2018 20.40, Dmitry Gutov wrote:
> On 22.11.2018 16:12, Dmitry Gutov wrote:
> 
>> I have just tried a --with-cairo build of the latest master, and can't repro any of the symptoms described here, as long as Emacs is launched with GDK_SCALE=1 (I have a HiDPI screen, and redisplay with scale=2 looks very broken).
> 
> And with the current emacs-26 branch, even that is not a problem.
> 
> So to sum up, I'm failing to reproduce any of the problems described in this bug report. Could any of the previous commenters try?

I just tried it again, on master.  I can't reproduce the problem any more.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#23925: 25.0.95; display broken when maximizing frame

[YAMAMOTO Mitsuharu]

On Tue, 18 Dec 2018 04:28:17 +0900,
Clément Pit-Claudel wrote:
> 
> >> I have just tried a --with-cairo build of the latest master, and can't repro any of the symptoms described here, as long as Emacs is launched with GDK_SCALE=1 (I have a HiDPI screen, and redisplay with scale=2 looks very broken).
> > 
> > And with the current emacs-26 branch, even that is not a problem.
> > 
> > So to sum up, I'm failing to reproduce any of the problems described in this bug report. Could any of the previous commenters try?
> 
> I just tried it again, on master.  I can't reproduce the problem any more.

With cairo, I can still see the problem that enlarging the frame by
mouse does not update the newly added area on master, with XQuartz on
macOS.  The following patch works for me.

Does the OP still have the similar problem on master?  If so, could
you try the patch below?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

diff --git a/src/xterm.c b/src/xterm.c
index 1b0c2f5ec5..ec89091d2a 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -299,6 +299,10 @@ record_event (char *locus, int type)
 
 #define FRAME_CR_CONTEXT(f)	((f)->output_data.x->cr_context)
 #define FRAME_CR_SURFACE(f)	((f)->output_data.x->cr_surface)
+#define FRAME_CR_SURFACE_DESIRED_WIDTH(f) \
+  ((f)->output_data.x->cr_surface_desired_width)
+#define FRAME_CR_SURFACE_DESIRED_HEIGHT(f) \
+  ((f)->output_data.x->cr_surface_desired_height)
 
 static struct x_gc_ext_data *
 x_gc_get_ext_data (struct frame *f, GC gc, int create_if_not_found_p)
@@ -333,6 +337,22 @@ x_extension_initialize (struct x_display_info *dpyinfo)
   dpyinfo->ext_codes = ext_codes;
 }
 
+static void
+x_cr_set_surface_desired_size (struct frame *f, int width, int height)
+{
+  cairo_surface_t *surface = FRAME_CR_SURFACE (f);
+
+  if (surface
+      && cairo_image_surface_get_width (surface) == width
+      && cairo_image_surface_get_height (surface) == height)
+    FRAME_CR_SURFACE_DESIRED_WIDTH (f) = 0;
+  else
+    {
+      FRAME_CR_SURFACE_DESIRED_WIDTH (f) = width;
+      FRAME_CR_SURFACE_DESIRED_HEIGHT (f) = height;
+    }
+}
+
 static void
 x_cr_destroy_surface (struct frame *f)
 {
@@ -350,22 +370,24 @@ cairo_t *
 x_begin_cr_clip (struct frame *f, GC gc)
 {
   cairo_t *cr = FRAME_CR_CONTEXT (f);
+  cairo_surface_t *surface = FRAME_CR_SURFACE (f);
 
-  if (!cr)
+  if (! surface || FRAME_CR_SURFACE_DESIRED_WIDTH (f))
     {
+      if (surface)
+	cairo_surface_destroy (surface);
 
-      if (! FRAME_CR_SURFACE (f))
-        {
-	  int scale = 1;
-#ifdef USE_GTK
-	  scale = xg_get_scale (f);
-#endif
+      FRAME_CR_SURFACE (f) =
+	cairo_image_surface_create (CAIRO_FORMAT_ARGB32,
+				    FRAME_CR_SURFACE_DESIRED_WIDTH (f),
+				    FRAME_CR_SURFACE_DESIRED_HEIGHT (f));
+      FRAME_CR_SURFACE_DESIRED_WIDTH (f) = 0;
 
-	  FRAME_CR_SURFACE (f) =
-	    cairo_image_surface_create (CAIRO_FORMAT_ARGB32,
-					scale * FRAME_PIXEL_WIDTH (f),
-					scale * FRAME_PIXEL_HEIGHT (f));
-	}
+      if (cr) cairo_destroy (cr);
+      cr = NULL;
+    }
+  if (!cr)
+    {
       cr = cairo_create (FRAME_CR_SURFACE (f));
       FRAME_CR_CONTEXT (f) = cr;
     }
@@ -989,41 +1011,7 @@ x_set_frame_alpha (struct frame *f)
 static void
 x_update_begin (struct frame *f)
 {
-#ifdef USE_CAIRO
-  if (FRAME_TOOLTIP_P (f) && !FRAME_VISIBLE_P (f))
-    return;
-
-  if (! FRAME_CR_SURFACE (f))
-    {
-      int width, height;
-#ifdef USE_GTK
-      if (FRAME_GTK_WIDGET (f))
-        {
-          GdkWindow *w = gtk_widget_get_window (FRAME_GTK_WIDGET (f));
-	  int scale = xg_get_scale (f);
-	  width = scale * gdk_window_get_width (w);
-	  height = scale * gdk_window_get_height (w);
-        }
-      else
-#endif
-        {
-          width = FRAME_PIXEL_WIDTH (f);
-          height = FRAME_PIXEL_HEIGHT (f);
-          if (! FRAME_EXTERNAL_TOOL_BAR (f))
-            height += FRAME_TOOL_BAR_HEIGHT (f);
-          if (! FRAME_EXTERNAL_MENU_BAR (f))
-            height += FRAME_MENU_BAR_HEIGHT (f);
-        }
-
-      if (width > 0 && height > 0)
-        {
-          block_input();
-          FRAME_CR_SURFACE (f) = cairo_image_surface_create
-            (CAIRO_FORMAT_ARGB32, width, height);
-          unblock_input();
-        }
-    }
-#endif /* USE_CAIRO */
+  /* Nothing to do.  */
 }
 
 /* Start update of window W.  */
@@ -8772,7 +8760,9 @@ handle_one_xevent (struct x_display_info *dpyinfo,
         font_drop_xrender_surfaces (f);
       unblock_input ();
 #ifdef USE_CAIRO
-      if (f) x_cr_destroy_surface (f);
+      if (f)
+	x_cr_set_surface_desired_size (f, configureEvent.xconfigure.width,
+				       configureEvent.xconfigure.height);
 #endif
 #ifdef USE_GTK
       if (!f
@@ -8786,7 +8776,8 @@ handle_one_xevent (struct x_display_info *dpyinfo,
           xg_frame_resized (f, configureEvent.xconfigure.width,
                             configureEvent.xconfigure.height);
 #ifdef USE_CAIRO
-          x_cr_destroy_surface (f);
+	  x_cr_set_surface_desired_size (f, configureEvent.xconfigure.width,
+					 configureEvent.xconfigure.height);
 #endif
           f = 0;
         }
@@ -11834,7 +11825,7 @@ x_free_frame_resources (struct frame *f)
 	free_frame_xic (f);
 #endif
 
-      x_free_cr_resources (f);
+      x_cr_destroy_surface (f);
 #ifdef USE_X_TOOLKIT
       if (f->output_data.x->widget)
 	{
diff --git a/src/xterm.h b/src/xterm.h
index 972a10f4d4..3456e12d84 100644
--- a/src/xterm.h
+++ b/src/xterm.h
@@ -744,6 +744,10 @@ struct x_output
   cairo_t *cr_context;
   /* Cairo surface for double buffering */
   cairo_surface_t *cr_surface;
+  /* Size reported by the last ConfigureNotify event.  The value of
+     cr_surface_desired_width is 0 when the size matches with that of
+     cr_surface above.  */
+  int cr_surface_desired_width, cr_surface_desired_height;
 #endif
 };
 

bug#23925: 25.0.95; display broken when maximizing frame

[Clément Pit-Claudel]

[-- Attachment #1.1.1: Type: text/plain, Size: 1202 bytes --]

On 2018-12-17 14:28, Clément Pit-Claudel wrote:
> On 10/12/2018 20.40, Dmitry Gutov wrote:
>> On 22.11.2018 16:12, Dmitry Gutov wrote:
>>
>>> I have just tried a --with-cairo build of the latest master, and can't repro any of the symptoms described here, as long as Emacs is launched with GDK_SCALE=1 (I have a HiDPI screen, and redisplay with scale=2 looks very broken).
>>
>> And with the current emacs-26 branch, even that is not a problem.
>>
>> So to sum up, I'm failing to reproduce any of the problems described in this bug report. Could any of the previous commenters try?
> 
> I just tried it again, on master.  I can't reproduce the problem any more.

I can reproduce the issue again.  

On 26 Mar 2019, Yamamoto Mitsuharu wrote:
> Does the OP still have the similar problem on master?  If so, could
> you try the patch below?

The patch doesn't apply any more for me :/ Could you refresh it?

My current recipe is this:

  src/emacs -Q --eval "(progn (load-theme 'tango-dark t) (sleep-for 1) (setq-default initial-frame-alist '((fullscreen . maximized))) (tool-bar-mode -1) (menu-bar-mode -1))"

It produces a display similar to the screenshot attached.

Clément.

[-- Attachment #1.1.2: Screenshot from 2019-06-18 14-54-58.png --]
[-- Type: image/png, Size: 82176 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#23925: 25.0.95; display broken when maximizing frame

[Dmitry Gutov]

On 18.06.2019 23:03, Clément Pit-Claudel wrote:
> src/emacs -Q --eval "(progn (load-theme 'tango-dark t) (sleep-for 1) (setq-default initial-frame-alist '((fullscreen . maximized))) (tool-bar-mode -1) (menu-bar-mode -1))"

I'm also (again?) seeing a related bug under GNU/Linux/X11 if I in 
addition to this command I press C-s-<down> followed by C-s-<up>, which 
are the shortcuts for "unmaximize" and "maximize". If I press C-s-<up> 
again, the problem clears.

I've made two videos, both show the screen imperfectly, however. The 
first one only captures the Emacs window, so somehow the unmaximized 
state is not noticeable. The second only shows the upper left quarter of 
the screen. But you can notice the problem there on the right.

https://imgur.com/a/MOxlVFZ

bug#23925: 25.0.95; display broken when maximizing frame

[YAMAMOTO Mitsuharu]

On Wed, 19 Jun 2019 06:33:33 +0900,
Dmitry Gutov wrote:
> 
> On 18.06.2019 23:03, Clément Pit-Claudel wrote:
> > src/emacs -Q --eval "(progn (load-theme 'tango-dark t) (sleep-for 1) (setq-default initial-frame-alist '((fullscreen . maximized))) (tool-bar-mode -1) (menu-bar-mode -1))"
> 
> I'm also (again?) seeing a related bug under GNU/Linux/X11 if I in
> addition to this command I press C-s-<down> followed by C-s-<up>,
> which are the shortcuts for "unmaximize" and "maximize". If I press
> C-s-<up> again, the problem clears.

Could you try adding (inhibit-double-buffering . t) to
initial-frame-alist above and see if the problem still happens?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

bug#23925: 25.0.95; display broken when maximizing frame

[Dmitry Gutov]

On 19.06.2019 3:26, YAMAMOTO Mitsuharu wrote:
> Could you try adding (inhibit-double-buffering . t) to
> initial-frame-alist above and see if the problem still happens?

Tried it now. The problem went away.

bug#23925: 25.0.95; display broken when maximizing frame

[YAMAMOTO Mitsuharu]

On Wed, 19 Jun 2019 10:22:40 +0900,
Dmitry Gutov wrote:
> 
> On 19.06.2019 3:26, YAMAMOTO Mitsuharu wrote:
> > Could you try adding (inhibit-double-buffering . t) to
> > initial-frame-alist above and see if the problem still happens?
> 
> Tried it now. The problem went away.

Thanks for trying.  Could you also try the following patch (without
inhibiting double buffering)?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

diff --git a/src/xterm.c b/src/xterm.c
index bc56e99513d..9bb0b83916c 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -8834,7 +8834,7 @@ handle_one_xevent (struct x_display_info *dpyinfo,
       if (f && FRAME_X_DOUBLE_BUFFERED_P (f))
         font_drop_xrender_surfaces (f);
       unblock_input ();
-#ifdef USE_CAIRO
+#if defined USE_CAIRO && !defined USE_GTK
       if (f)
 	x_cr_update_surface_desired_size (f, configureEvent.xconfigure.width,
 					  configureEvent.xconfigure.height);

bug#23925: 25.0.95; display broken when maximizing frame

[Dmitry Gutov]

On 19.06.2019 4:38, YAMAMOTO Mitsuharu wrote:
> Thanks for trying.  Could you also try the following patch (without
> inhibiting double buffering)?

It helps: I don't see this problem anymore. Thank you!

(If you could also take a look at bug#36284 I just filed, that would be 
much appreciated).

bug#23925: 25.0.95; display broken when maximizing frame

[Clément Pit-Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 487 bytes --]

On 2019-06-18 21:38, YAMAMOTO Mitsuharu wrote:
> On Wed, 19 Jun 2019 10:22:40 +0900,
> Dmitry Gutov wrote:
>>
>> On 19.06.2019 3:26, YAMAMOTO Mitsuharu wrote:
>>> Could you try adding (inhibit-double-buffering . t) to
>>> initial-frame-alist above and see if the problem still happens?
>>
>> Tried it now. The problem went away.
> 
> Thanks for trying.  Could you also try the following patch (without
> inhibiting double buffering)?

That works for me too :)  Thanks!



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#23925: 25.0.95; display broken when maximizing frame

[YAMAMOTO Mitsuharu]

On Wed, 19 Jun 2019 23:07:06 +0900,
Clément Pit-Claudel wrote:
>
> > Thanks for trying.  Could you also try the following patch (without
> > inhibiting double buffering)?
> 
> That works for me too :)  Thanks!

The patch is installed on master as 2da3305c3c3.  Closing the bug.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

bug#23925: 25.0.95; display broken when maximizing frame

[Roland Winkler]

On Wed Jun 19 2019 Dmitry Gutov wrote:
> On 19.06.2019 3:26, YAMAMOTO Mitsuharu wrote:
> > Could you try adding (inhibit-double-buffering . t) to
> > initial-frame-alist above and see if the problem still happens?
> 
> Tried it now. The problem went away.

For the records: Today, after a long time, I again built emacs from
master with cairo enabled.  From what I can tell so far, it is
running fine.

bug#23925: 25.0.95; display broken when maximizing frame

[YAMAMOTO Mitsuharu]

On Wed, 19 Jun 2019 05:03:51 +0900,
Clément Pit-Claudel wrote:
> 
> I can reproduce the issue again.  
> 
> On 26 Mar 2019, Yamamoto Mitsuharu wrote:
> > Does the OP still have the similar problem on master?  If so, could
> > you try the patch below?
> 
> The patch doesn't apply any more for me :/ Could you refresh it?

The patch has already been applied on master in a different form.  It
surely fixed some problem with resizing by mouse dragging.  But it
seems that another problem has been reintroduced.

> My current recipe is this:
> 
>   src/emacs -Q --eval "(progn (load-theme 'tango-dark t) (sleep-for 1) (setq-default initial-frame-alist '((fullscreen . maximized))) (tool-bar-mode -1) (menu-bar-mode -1))"
> 
> It produces a display similar to the screenshot attached.

Thanks.  I could reproduce it on Linux Mint 18.3 with GTK+3 and GTK+2
builds.  On the other hand, none of --with-x-toolkit=no/athena/motif
exhibits this problem.  Probably this has something to do with
GTK+-specific code.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

bug#23925: 25.0.95; display broken when maximizing frame

[Dmitry Gutov]

On 09.07.2016 12:45, Clément Pit--Claudel wrote:
> - Not sure if it's related or if it should be another bug: font anti-aliasing is not the same when when maximized and unmaximized (see screenshots).

With possible exception of this part. I do see somewhat different font 
rendering with and without Cairo.

bug#23925: 25.0.95; display broken when maximizing frame

[Robert Pluim]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 09.07.2016 12:45, Clément Pit--Claudel wrote:
>> - Not sure if it's related or if it should be another bug: font
>> anti-aliasing is not the same when when maximized and unmaximized
>> (see screenshots).
>
> With possible exception of this part. I do see somewhat different font
> rendering with and without Cairo.

I guess thatʼs because with Cairo Emacs uses a different font
backend. Can you describe the differences?

Robert

bug#23925: 25.0.95; display broken when maximizing frame

[Roland Winkler]

On Sat Jul 9 2016 Eli Zaretskii wrote:
> > Configured using:
> >  'configure --with-xwidgets --with-x-toolkit=gtk3 --with-cairo'
> 
> One idea I do have is to build without --with-cairo, and see if the
> problem goes away.  The Cairo back-end is still experimental, and we
> know of several problems with it.

I can confirm Clément's observation that the problem appears only
when cairo is used to build emacs.

I enabled cairo just out of curiosity.  I wouldn't mind if it got
completely disabled for 25.1 (or combined with noisy warnings that
cairo gives serious bugs).

On Sat Jul 9 2016 Eli Zaretskii wrote:
> > From: Glenn Morris <rgm@gnu.org>
> > Maybe with-cairo should be renamed to with-experimental-cairo or
> > somesuch, because simply describing it as experimental isn't
> > getting the message across.
> > 
> > It's unfinished, unmaintained, and has known issues.  Frankly I
> > suggest no-one uses it unless they are prepared to deal with the
> > resulting breakage.
> 
> What does that mean in practice, though?  We already have that option
> off by default, which should be enough of a hint to anybody that this
> option should not be turned on without a good reason.

The NEWS file made me believe that, in principle, cairo works...

  Cairo drawing is an experimental feature in Emacs, and subject to
  change in future releases.

...but merely one should not assume that cairo-related internals
stay what they are now.  The NEWS file could mention that emacs
build with cairo is still buggy.  Also, this could be mentioned in
PROBLEMS which does not talk at all about cairo.  (I do not know
which "known issues" you have in mind.  The redisplay bug is all I
noticed so far, but so far my testing has been very limited.)

On Sat Jul 9 2016 martin rudalics wrote:
> Please post the results after doing each of the following:
> 
> (1) Evaluate (display-monitor-attributes-list)

(((name . "DP2") (geometry 0 0 1920 1080) (workarea 0 25 1920 1055) (mm-size 510 287) (frames #<frame emacs@regnitz 0x1244a90>) (source . "Gdk")))

> (2) With the badly maximized frame evaluate (frame-geometry)

((outer-position 0 . 25) (outer-size 1913 . 1052) (external-border-size 5 . 5) (title-bar-size 0 . 18) (menu-bar-external . t) (menu-bar-size 1903 . 22) (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 0 . 0) (internal-border-width . 1))

> In this state please also evaluate (window--dump-frame)

frame pixel: 1903 x 1002   cols/lines: 191 x 50   units: 10 x 20
frame text pixel: 1870 x 1000   cols/lines: 187 x 50
tool: 0  scroll: 15/0  fringe: 16  border: 1  right: 0  bottom: 0

#<window 3 on *Messages*>   parent: nil
pixel left: 0   top: 0   size: 1901 x 980   new: 820
char left: 0   top: 0   size: 190 x 49   new: 38
normal: 1.0 x 1.0   new: nil
body pixel: 1870 x 960   char: 187 x 48
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 15  divider: 0
height header-line: 0  mode-line: 20  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 980   size: 1901 x 20   new: 0
char left: 0   top: 49   size: 190 x 1   new: 1
normal: 1.0 x 1.0   new: 0
body pixel: 1870 x 20   char: 187 x 1
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 15  divider: 0
height header-line: 0  mode-line: 0  divider: 0

> (3) Before maximizing evaluate (setq frame-size-history '(5))
>      Then maximize and evaluate (frame--size-history).  The result can be
>      found in the buffer *frame-size-history*.

Frame size history of #<frame emacs@regnitz 0x1244a90>
x-handle-net-wm-state    nil (nil nil)
x-handle-net-wm-state    nil (nil nil)
x-net-wm-state           nil (nil maximized)
x-net-wm-state           nil (maximized maximized)
x-handle-net-wm-state    nil (maximized maximized)

=======

Let me know if any other info might be useful.

Roland

bug#23925: 25.0.95; display broken when maximizing frame

[martin rudalics]

 > After a long time I build again a more recent emacs.  Unfortunately
 > it gives me a rather unpleasant experience when maximizing the emacs
 > frame (using the maximize function of the xfce window manager):
 > somehow the frame is not redrawn properly, emacs seems to be unaware
 > of the new frame size and the minibuffer disappears completely.
 > Instead the desktop background is displayed in large parts of the
 > emacs frame.  Unmaximizing makes the problem go away.  But obviously
 > that is no solution.  I can provide more details if you let me know
 > what would be interesting.
 >
 >
 >
 >
 > In GNU Emacs 25.0.95.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.18.9, cairo version 1.14.6)
 >   of 2016-07-08 built on regnitz
 > Windowing system distributor 'The X.Org Foundation', version 11.0.11803000
 > System Description:	Ubuntu 16.04 LTS
 >
 > Configured using:
 >   'configure --with-xwidgets --with-x-toolkit=gtk3 --with-cairo'

Please post the results after doing each of the following:

(1) Evaluate (display-monitor-attributes-list)

(2) With the badly maximized frame evaluate (frame-geometry)

(3) Before maximizing evaluate (setq frame-size-history '(5))
     Then maximize and evaluate (frame--size-history).  The result can be
     found in the buffer *frame-size-history*.

And obviously please also follow Eli's proposal to build without cairo.

Thanks, martin

bug#23925: 25.0.95; display broken when maximizing frame

[Glenn Morris]

Maybe with-cairo should be renamed to with-experimental-cairo or somesuch,
because simply describing it as experimental isn't getting the message across.

It's unfinished, unmaintained, and has known issues.
Frankly I suggest no-one uses it unless they are prepared to deal with
the resulting breakage.

Ref eg
http://lists.gnu.org/archive/html/emacs-devel/2015-05/msg00689.html

bug#23925: 25.0.95; display broken when maximizing frame

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Sat, 09 Jul 2016 13:32:36 -0400
> Cc: 23925@debbugs.gnu.org
> 
> Maybe with-cairo should be renamed to with-experimental-cairo or somesuch,
> because simply describing it as experimental isn't getting the message across.
> 
> It's unfinished, unmaintained, and has known issues.
> Frankly I suggest no-one uses it unless they are prepared to deal with
> the resulting breakage.

What does that mean in practice, though?  We already have that option
off by default, which should be enough of a hint to anybody that this
option should not be turned on without a good reason.

bug#23925: 25.0.95; display broken when maximizing frame

[Glenn Morris]

Eli Zaretskii wrote:

> What does that mean in practice, though?  We already have that option
> off by default, which should be enough of a hint to anybody that this
> option should not be turned on without a good reason.

Probably overkill, but eg:

--- a/configure.ac
+++ b/configure.ac
@@ -3164,6 +3164,13 @@ AC_SUBST(M17N_FLT_LIBS)
 HAVE_CAIRO=no
 if test "${HAVE_X11}" = "yes"; then
   if test "${with_cairo}" != "no"; then
+
+    AC_MSG_WARN([The Emacs Cairo port is experimental and unmaintained,
+and not recommended for use by non-developers.  There are several
+known display problems.  Please do not report display-related bugs in Cairo
+builds unless you are willing to fix them yourself.])
+    sleep 3
+
     CAIRO_REQUIRED=1.12.0
     CAIRO_MODULE="cairo >= $CAIRO_REQUIRED"
     EMACS_CHECK_MODULES(CAIRO, $CAIRO_MODULE)


(since AFAICS we have no-one who can work on these issues.)

bug#23925: 25.0.95; display broken when maximizing frame

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: winkler@gnu.org,  23925@debbugs.gnu.org
> Date: Sat, 09 Jul 2016 21:03:35 -0400
> 
> +    AC_MSG_WARN([The Emacs Cairo port is experimental and unmaintained,
> +and not recommended for use by non-developers.  There are several
> +known display problems.  Please do not report display-related bugs in Cairo
> +builds unless you are willing to fix them yourself.])

Sounds a tad too extreme to me.  How about the following text instead?

  The Emacs Cairo port is experimental and still has some known
  display problems.  We encourage more testing of this port and
  reporting any problems you find, but it is not recommended for
  production.

bug#23925: 25.0.95; display broken when maximizing frame

[Roland Winkler]

On Sun Jul 10 2016 Eli Zaretskii wrote:
>   The Emacs Cairo port is experimental and still has some known
>   display problems.  We encourage more testing of this port and
>   reporting any problems you find, but it is not recommended for
>   production.

How about putting something like this also in the NEWS file.  The
current description of the cairo port in NEWS is rather optimistic
and it appears quite prominently as the very beginning of NEWS.
Someone who doesn't build emacs by himself but only reads NEWS might
then be disappointed if his build does not include the cairo port.
(The support for built-in printing described in NEWS sounds quite
attractive.  It's something I have missed for a long time.  Only few
people might recognize that the price for this is that cairo affects
all kinds of innermost emacs internals beyond the built-in printing
support.  And the current status of this does not match the maturity
one is otherwise used to with released versions of emacs.)

(I am not even sure I'd wanted to call the cairo port an
"Installation Change", which again suggests to me that it was a less
significant change.)

Roland

bug#23925: 25.0.95; display broken when maximizing frame

[Eli Zaretskii]

> Date: Fri, 15 Jul 2016 10:46:21 -0500
> From: "Roland Winkler" <winkler@gnu.org>
> Cc: Glenn Morris <rgm@gnu.org>,
>     23925@debbugs.gnu.org
> 
> On Sun Jul 10 2016 Eli Zaretskii wrote:
> >   The Emacs Cairo port is experimental and still has some known
> >   display problems.  We encourage more testing of this port and
> >   reporting any problems you find, but it is not recommended for
> >   production.
> 
> How about putting something like this also in the NEWS file.

Fine with me.

bug#23925: 25.0.95; display broken when maximizing frame

[Eli Zaretskii]

> Date: Fri, 15 Jul 2016 10:46:21 -0500
> From: "Roland Winkler" <winkler@gnu.org>
> Cc: Glenn Morris <rgm@gnu.org>,
>     23925@debbugs.gnu.org
> 
> On Sun Jul 10 2016 Eli Zaretskii wrote:
> >   The Emacs Cairo port is experimental and still has some known
> >   display problems.  We encourage more testing of this port and
> >   reporting any problems you find, but it is not recommended for
> >   production.
> 
> How about putting something like this also in the NEWS file.

Done.