Po,

> what happens if you place:
>
> (setq w32-disable-double-buffering t)
>
> in your early-init.el?

It helps, but doesn't remove the bright flash altogether. Hard to tell, but I believe it shortens the time of the flash to just one frame. For comparison: 28.2 doesn't have any perceptible bright flash.

I will have some time over the weekend to look at the code, but I haven't seen the Emacs codebase yet, so I might be taking more than I can handle. Can you give me any pointers where to look?

On Wed, Jul 26, 2023 at 2:35 PM Po Lu <luangruo@yahoo.com> wrote:

Eli Zaretskii <eliz@gnu.org> writes:

> Maybe. I don't know enough about the low-level details of the Emacs
> display on Windows to tell.

Could this be related to the new MS-Windows double buffering code?

When WM_ERASEBKGND arrives and double buffering is enabled, Emacs simply
copies the back buffer contents to the front buffer HWND. Perhaps this
bug is a result of the copy transpiring in between the creation of the
back buffer, and when redisplay first clears the frame with its
background color. In that case, the solution is for the back buffer to
always be filled with the frame background color after every time it is
created, instead of whichever color CreateCompatibleBitmap opts to fill
it with by default.

Yachani, what happens if you place:

(setq w32-disable-double-buffering t)

in your early-init.el?