bug#55208: 29.0.50; MS-Windows GUI selection dialogs and double-buffering

bug#55208: 29.0.50; MS-Windows GUI selection dialogs and double-buffering

[Eli Zaretskii]

The double-buffering feature on MS-Windows has one unpleasant
side-effect: when the user opens any GUI selection dialog that is
provided by the MS-Windows "toolkit", dragging that dialog leaves its
"ghost" shown in the Emacs frame.

To reproduce:

 emacs -Q
 Click File->Open File
 Drag the file selection dialog with the mouse
 Observe that the dialog is indeed dragged, as expected, but it leaves
 its "ghost" at the original position

I think this is related to the fact that, as long as the selection
dialog is open, we don't update the Emacs display.  With
double-buffering disabled, the area across which the dialog is dragged
is cleared (the text is not "erased", and only the background
remains).  Which is also not very nice, but it's much more subtle, so
much so that I don't recall any bug reports about this.  Showing the
"ghost" of the menu there is much more prominent, so I hope we could
at least go back to what we have without double-buffering.  Bonus
points for redrawing the text while the dialog is being dragged.



In GNU Emacs 29.0.50 (build 968, i686-pc-mingw32)
 of 2022-05-01 built on HOME-C4E4A596F7
Repository revision: 9370a4763aacbb9278b5be9c92a2484e3652bc29
Repository branch: master
Windowing system distributor 'Microsoft Corp.', version 5.1.2600
System Description: Microsoft Windows XP Service Pack 3 (v5.1.0.2600)

Configured using:
 'configure -C --prefix=/d/usr --with-wide-int
 --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3''

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY
W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS WEBP XPM ZLIB

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1255

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-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
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media rmc puny
rfc822 mml mml-sec password-cache epa derived epg rfc6068 epg-config
gnus-util text-property-search time-date seq gv subr-x byte-opt bytecomp
byte-compile cconv mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils dired dired-loaddefs
face-remap iso-transl tooltip eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel dos-w32 ls-lisp disp-table
term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice simple cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop
case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads
w32notify w32 lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 49989 12437)
 (symbols 48 6902 1)
 (strings 16 19268 3097)
 (string-bytes 1 540461)
 (vectors 16 11301)
 (vector-slots 8 161753 13124)
 (floats 8 25 198)
 (intervals 40 340 71)
 (buffers 888 10))

bug#55208: 29.0.50; MS-Windows GUI selection dialogs and double-buffering

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> The double-buffering feature on MS-Windows has one unpleasant
> side-effect: when the user opens any GUI selection dialog that is
> provided by the MS-Windows "toolkit", dragging that dialog leaves its
> "ghost" shown in the Emacs frame.
>
> To reproduce:
>
>  emacs -Q
>  Click File->Open File
>  Drag the file selection dialog with the mouse
>  Observe that the dialog is indeed dragged, as expected, but it leaves
>  its "ghost" at the original position
>
> I think this is related to the fact that, as long as the selection
> dialog is open, we don't update the Emacs display.  With
> double-buffering disabled, the area across which the dialog is dragged
> is cleared (the text is not "erased", and only the background
> remains).  Which is also not very nice, but it's much more subtle, so
> much so that I don't recall any bug reports about this.  Showing the
> "ghost" of the menu there is much more prominent, so I hope we could
> at least go back to what we have without double-buffering.  Bonus
> points for redrawing the text while the dialog is being dragged.

I think the version of MS Windows I used to test the double-buffering
feature doesn't overwrite the contents of windows underneath the topmost
window, which is why I don't see that bug.

But try adding some code along the following lines under `WM_PAINT' in
`w32_msg_pump':

  	if (popup is active)
	  {
	    enter_crit ();
	    if (FRAME_OUTPUT_DATA (f)->paint_dc)
	      {
		BeginPaint (hwnd, &paintStruct);

		BitBlt (FRAME_OUTPUT_DATA (f)->paint_buffer_handle,
			0, 0, FRAME_PIXEL_WIDTH (f), FRAME_PIXEL_HEIGHT (f),
			FRAME_OUTPUT_DATA (f)->paint_dc, 0, 0, SRCCOPY);

		EndPaint (hwnd, &paintStruct);
	      }
	    leave_crit ();

	    return 0;
	  }

(I don't know how to implement the "popup is active" part,
unfortunately.)

Thanks.

bug#55208: 29.0.50; MS-Windows GUI selection dialogs and double-buffering

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: 55208@debbugs.gnu.org
> Date: Mon, 02 May 2022 09:10:53 +0800
> 
> I think the version of MS Windows I used to test the double-buffering
> feature doesn't overwrite the contents of windows underneath the topmost
> window, which is why I don't see that bug.

What _do_ you see when you drag the selection dialog box with the
mouse?

bug#55208: 29.0.50; MS-Windows GUI selection dialogs and double-buffering

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> What _do_ you see when you drag the selection dialog box with the
> mouse?

Nothing out of the ordinary: the contents in the frame underneath the
selection dialog box are preserved.

bug#55208: 29.0.50; MS-Windows GUI selection dialogs and double-buffering

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: 55208@debbugs.gnu.org
> Date: Mon, 02 May 2022 09:10:53 +0800
> 
> But try adding some code along the following lines under `WM_PAINT' in
> `w32_msg_pump':

w32_msg_pump doesn't handle WM_PAINT, so I'm not sure what you mean
here.  Also, AFAIK w32_msg_pump runs in a separate thread, so is it
safe to call BitBlt from that thread?

>   	if (popup is active)
> 	  {
> 	    enter_crit ();
> 	    if (FRAME_OUTPUT_DATA (f)->paint_dc)
> 	      {
> 		BeginPaint (hwnd, &paintStruct);
> 
> 		BitBlt (FRAME_OUTPUT_DATA (f)->paint_buffer_handle,
> 			0, 0, FRAME_PIXEL_WIDTH (f), FRAME_PIXEL_HEIGHT (f),
> 			FRAME_OUTPUT_DATA (f)->paint_dc, 0, 0, SRCCOPY);
> 
> 		EndPaint (hwnd, &paintStruct);
> 	      }
> 	    leave_crit ();
> 
> 	    return 0;
> 	  }
> 
> (I don't know how to implement the "popup is active" part,
> unfortunately.)

I do know, but the above issues bother me more, so I didn't yet try
this.

Thanks.

bug#55208: 29.0.50; MS-Windows GUI selection dialogs and double-buffering

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> w32_msg_pump doesn't handle WM_PAINT, so I'm not sure what you mean
> here.  Also, AFAIK w32_msg_pump runs in a separate thread, so is it
> safe to call BitBlt from that thread?

Sorry, I meant `w32_msg_pump'.  But it should be safe as long as the
painting is done inside the critical section, which protects all
modifications to the paint buffer (and its handle.)

> I do know, but the above issues bother me more, so I didn't yet try
> this.

I tried to explain above, thanks.

bug#55208: 29.0.50; MS-Windows GUI selection dialogs and double-buffering

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: 55208@debbugs.gnu.org
> Date: Sat, 07 May 2022 16:26:39 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > w32_msg_pump doesn't handle WM_PAINT, so I'm not sure what you mean
> > here.  Also, AFAIK w32_msg_pump runs in a separate thread, so is it
> > safe to call BitBlt from that thread?
> 
> Sorry, I meant `w32_msg_pump'.

That's what I said: w32_msg_pump doesn't currently handle WM_PAINT, it
only handles WM_EMACS_* messages we send to it.  Did you mean
w32_wnd_proc instead?  Or what am I missing?

bug#55208: 29.0.50; MS-Windows GUI selection dialogs and double-buffering

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> That's what I said: w32_msg_pump doesn't currently handle WM_PAINT, it
> only handles WM_EMACS_* messages we send to it.  Did you mean
> w32_wnd_proc instead?  Or what am I missing?

Silly me!  I did indeed mean `w32_wnd_proc'.

Thanks.

bug#55208: 29.0.50; MS-Windows GUI selection dialogs and double-buffering

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: 55208@debbugs.gnu.org
> Date: Sat, 07 May 2022 17:19:18 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > That's what I said: w32_msg_pump doesn't currently handle WM_PAINT, it
> > only handles WM_EMACS_* messages we send to it.  Did you mean
> > w32_wnd_proc instead?  Or what am I missing?
> 
> Silly me!  I did indeed mean `w32_wnd_proc'.

Thanks, the below seems to fix the problem here on XP.  Does the patch
look reasonable, and if so, could you perhaps test it on some newer
version of Windows, to see that it doesn't cause any regressions
there?

diff --git a/src/w32fns.c b/src/w32fns.c
index 0f25c1a..d2da943 100644
--- a/src/w32fns.c
+++ b/src/w32fns.c
@@ -247,6 +247,8 @@ #define MENU_FREE_DELAY 1000
 
 static int w32_unicode_gui;
 
+static struct frame *w32_selection_dialog_open_frame = NULL;
+
 /* From w32menu.c  */
 int menubar_in_use = 0;
 
@@ -4184,6 +4186,16 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
 		       update_rect.left, update_rect.top,
 		       update_rect.right, update_rect.bottom));
 #endif
+	    /* Under double-buffering, update the frame from the back
+	       buffer, to prevent a "ghost" of the selection dialog to
+	       be left on display while the user selects in the dialog.  */
+	    if (w32_selection_dialog_open_frame == f
+		&& !w32_disable_double_buffering
+		&& FRAME_OUTPUT_DATA (f)->paint_dc)
+	      BitBlt (FRAME_OUTPUT_DATA (f)->paint_buffer_handle,
+		      0, 0, FRAME_PIXEL_WIDTH (f), FRAME_PIXEL_HEIGHT (f),
+		      FRAME_OUTPUT_DATA (f)->paint_dc, 0, 0, SRCCOPY);
+
 	    EndPaint (hwnd, &paintStruct);
 	    leave_crit ();
 
@@ -7754,6 +7766,16 @@ file_dialog_callback (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
 w32_dialog_in_progress (Lisp_Object in_progress)
 {
   Lisp_Object frames, frame;
+  struct frame *f = SELECTED_FRAME ();
+
+  /* If the current frame has double-buffering enabled, indicate to
+     w32_wnd_proc that the selection dialog is about to be open.  */
+  if (FRAME_OUTPUT_DATA (f)->want_paint_buffer)
+    {
+      enter_crit ();
+      w32_selection_dialog_open_frame = NILP (in_progress) ? NULL : f;
+      leave_crit ();
+    }
 
   /* Don't let frames in `above' z-group obscure dialog windows.  */
   FOR_EACH_FRAME (frames, frame)

bug#55208: 29.0.50; MS-Windows GUI selection dialogs and double-buffering

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> Thanks, the below seems to fix the problem here on XP.  Does the patch
> look reasonable, and if so, could you perhaps test it on some newer
> version of Windows, to see that it doesn't cause any regressions
> there?

I don't have access to the Windows machine(s) at this time of day.  The
patch looks good to me (though I wonder what happens if a WM_PAINT
message is received for a frame other than
`w32_selection_dialog_open_frame'), and I will test it ASAP.

Thanks.

bug#55208: 29.0.50; MS-Windows GUI selection dialogs and double-buffering

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: 55208@debbugs.gnu.org
> Date: Sat, 07 May 2022 18:23:10 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Thanks, the below seems to fix the problem here on XP.  Does the patch
> > look reasonable, and if so, could you perhaps test it on some newer
> > version of Windows, to see that it doesn't cause any regressions
> > there?
> 
> I don't have access to the Windows machine(s) at this time of day.  The
> patch looks good to me (though I wonder what happens if a WM_PAINT
> message is received for a frame other than
> `w32_selection_dialog_open_frame')

Hmm... you are right.  An updated patch below.

> and I will test it ASAP.

Thanks.

diff --git a/src/w32fns.c b/src/w32fns.c
index 0f25c1a..e5becb5 100644
--- a/src/w32fns.c
+++ b/src/w32fns.c
@@ -247,6 +247,8 @@ #define MENU_FREE_DELAY 1000
 
 static int w32_unicode_gui;
 
+static bool w32_selection_dialog_open;
+
 /* From w32menu.c  */
 int menubar_in_use = 0;
 
@@ -4184,6 +4186,16 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
 		       update_rect.left, update_rect.top,
 		       update_rect.right, update_rect.bottom));
 #endif
+	    /* Under double-buffering, update the frame from the back
+	       buffer, to prevent a "ghost" of the selection dialog to
+	       be left on display while the user selects in the dialog.  */
+	    if (w32_selection_dialog_open
+		&& !w32_disable_double_buffering
+		&& FRAME_OUTPUT_DATA (f)->paint_dc)
+	      BitBlt (FRAME_OUTPUT_DATA (f)->paint_buffer_handle,
+		      0, 0, FRAME_PIXEL_WIDTH (f), FRAME_PIXEL_HEIGHT (f),
+		      FRAME_OUTPUT_DATA (f)->paint_dc, 0, 0, SRCCOPY);
+
 	    EndPaint (hwnd, &paintStruct);
 	    leave_crit ();
 
@@ -7755,6 +7767,15 @@ w32_dialog_in_progress (Lisp_Object in_progress)
 {
   Lisp_Object frames, frame;
 
+  /* Indicate to w32_wnd_proc that the selection dialog is about to be
+     open (or was closed, if IN_PROGRESS is nil).  */
+  if (!w32_disable_double_buffering)
+    {
+      enter_crit ();
+      w32_selection_dialog_open = !NILP (in_progress);
+      leave_crit ();
+    }
+
   /* Don't let frames in `above' z-group obscure dialog windows.  */
   FOR_EACH_FRAME (frames, frame)
     {

bug#55208: 29.0.50; MS-Windows GUI selection dialogs and double-buffering

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> diff --git a/src/w32fns.c b/src/w32fns.c
> index 0f25c1a..e5becb5 100644
> --- a/src/w32fns.c
> +++ b/src/w32fns.c
> @@ -247,6 +247,8 @@ #define MENU_FREE_DELAY 1000
>  
>  static int w32_unicode_gui;
>  
> +static bool w32_selection_dialog_open;
> +
>  /* From w32menu.c  */
>  int menubar_in_use = 0;
>  
> @@ -4184,6 +4186,16 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
>  		       update_rect.left, update_rect.top,
>  		       update_rect.right, update_rect.bottom));
>  #endif
> +	    /* Under double-buffering, update the frame from the back
> +	       buffer, to prevent a "ghost" of the selection dialog to
> +	       be left on display while the user selects in the dialog.  */
> +	    if (w32_selection_dialog_open
> +		&& !w32_disable_double_buffering
> +		&& FRAME_OUTPUT_DATA (f)->paint_dc)
> +	      BitBlt (FRAME_OUTPUT_DATA (f)->paint_buffer_handle,
> +		      0, 0, FRAME_PIXEL_WIDTH (f), FRAME_PIXEL_HEIGHT (f),
> +		      FRAME_OUTPUT_DATA (f)->paint_dc, 0, 0, SRCCOPY);
> +
>  	    EndPaint (hwnd, &paintStruct);
>  	    leave_crit ();
>  
> @@ -7755,6 +7767,15 @@ w32_dialog_in_progress (Lisp_Object in_progress)
>  {
>    Lisp_Object frames, frame;
>  
> +  /* Indicate to w32_wnd_proc that the selection dialog is about to be
> +     open (or was closed, if IN_PROGRESS is nil).  */
> +  if (!w32_disable_double_buffering)
> +    {
> +      enter_crit ();
> +      w32_selection_dialog_open = !NILP (in_progress);
> +      leave_crit ();
> +    }
> +
>    /* Don't let frames in `above' z-group obscure dialog windows.  */
>    FOR_EACH_FRAME (frames, frame)
>      {

This seems to work fine, please go ahead and install it.  Thanks.

bug#55208: 29.0.50; MS-Windows GUI selection dialogs and double-buffering

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: 55208@debbugs.gnu.org
> Date: Sun, 08 May 2022 13:33:40 +0800
> 
> This seems to work fine, please go ahead and install it.  Thanks.

Thanks.  Installed and closing the bug.