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" <bug-gnu-emacs@gnu.org>]

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.