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?
>