bug#53232: 29.0.50; pgtk startup: flashes white background before painting black

bug#53232: 29.0.50; pgtk startup: flashes white background before painting black

[John Yates]

emacs -Q --eval '(set-background-color "#000000")'

In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.30, cairo version 1.16.0)
 of 2022-01-12 built on envy
Repository revision: 492bf1e06edb4324a643ccb15dd6062762145f17
Repository branch: master
System Description: Ubuntu 21.10

Configured using:
 'configure --prefix=/usr/local/emacs
 '--program-transform-name=s/^ctags$/ctags.emacs/' --disable-year2038
 --disable-acl --with-modules --with-json --with-file-notification
 --with-native-compilation --with-xwidgets --with-pgtk'

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY
INOTIFY PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS WEBP XIM XWIDGETS GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

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
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media rmc puny
dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg
rfc6068 epg-config gnus-util text-property-search seq gv byte-opt
bytecomp byte-compile cconv mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils time-date subr-x cl-loaddefs
cl-lib iso-transl tooltip eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/pgtk-win pgtk-win
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 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 simple abbrev obarray cl-preloaded nadvice 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 xwidget-internal dbusbind
inotify dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit pgtk lcms2 multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 56373 12796)
 (symbols 48 5673 1)
 (strings 32 16368 1519)
 (string-bytes 1 536457)
 (vectors 16 11775)
 (vector-slots 8 264630 17626)
 (floats 8 25 40)
 (intervals 56 213 0)
 (buffers 992 10))


-- 
John Yates
505 Tremont St, #803
Boston, MA 02116

bug#53232: 29.0.50; pgtk startup: flashes white background before painting black

[Lars Ingebrigtsen]

John Yates <john@yates-sheets.org> writes:

> emacs -Q --eval '(set-background-color "#000000")'

You get the same in a non-pgtk built, too -- and I think that's to be
expected?  Emacs first pops up the frame and then starts doing the
--eval stuff, I think.

If you want to set the background colour in this manner, putting it in
the early init file should do the trick, if I remember correctly.

So I think everything here works as designed?  Anybody have any comments
here?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#53232: 29.0.50; pgtk startup: flashes white background before painting black

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 14 Jan 2022 08:52:45 +0100
> Cc: 53232@debbugs.gnu.org
> 
> John Yates <john@yates-sheets.org> writes:
> 
> > emacs -Q --eval '(set-background-color "#000000")'
> 
> You get the same in a non-pgtk built, too -- and I think that's to be
> expected?  Emacs first pops up the frame and then starts doing the
> --eval stuff, I think.

Yes.

bug#53232: 29.0.50; pgtk startup: flashes white background before painting black

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> You get the same in a non-pgtk built, too -- and I think that's to be
>> expected?  Emacs first pops up the frame and then starts doing the
>> --eval stuff, I think.
>
> Yes.

To summarise -- to avoid the flashes, you have to put something like

(add-to-list 'default-frame-alist '(background-color . "#000000"))

in the early-init.el file.  So I think everything works as designed
here, and I'm therefore closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#53232: reopen 53232

[John Yates]

I originally reported this issue via email to emacs-devel.
Stefan suggested that I try early-init.el and suggested
that a bug report would be more appropriate.

I attempted to use early-init.el without success and
so set about to submit a bug report.

My previous erroneous repro case

    emacs -Q --eval '(set-background-color "#000000")'

was an attempt to comply with the advice in the bug
template which asks for a -Q repro.

That said, the sub-optimal behavior is real:

* early-init.el:

    (custom-set-variables
     '(default-frame-alist
       '((fullscreen . maximized)
         (background-color . "#000000")
         (foreground-color . "#ffffff")))
     '(inhibit-startup-screen t)
    )

* init.el:

    [EMPTY]

This time, before being so quick to close, please
confirm that any suggested fix actually works.

My confusion about sequencing makes me think that
there might be a place for an --early-eval option.

bug#53232: reopen 53232

[Lars Ingebrigtsen]

John Yates <john@yates-sheets.org> writes:

> I originally reported this issue via email to emacs-devel.
> Stefan suggested that I try early-init.el and suggested
> that a bug report would be more appropriate.
>
> I attempted to use early-init.el without success and
> so set about to submit a bug report.
>
> My previous erroneous repro case
>
>     emacs -Q --eval '(set-background-color "#000000")'
>
> was an attempt to comply with the advice in the bug
> template which asks for a -Q repro.

Ah, I see.  OK, reopening.

> That said, the sub-optimal behavior is real:
>
> * early-init.el:
>
>     (custom-set-variables
>      '(default-frame-alist
>        '((fullscreen . maximized)
>          (background-color . "#000000")
>          (foreground-color . "#ffffff")))
>      '(inhibit-startup-screen t)
>     )
>
> * init.el:
>
>     [EMPTY]

I'm unable to reproduce this with or without pgtk -- Emacs doesn't flash
the default background colour on startup, as far as I can tell.  (This
is on Debian/bookworm with Gnome Shell, if that matters.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#53232: reopen 53232

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 17 Jan 2022 18:24:50 +0100
> Cc: Po Lu <luangruo@yahoo.com>, 53232@debbugs.gnu.org
> 
> > That said, the sub-optimal behavior is real:
> >
> > * early-init.el:
> >
> >     (custom-set-variables
> >      '(default-frame-alist
> >        '((fullscreen . maximized)
> >          (background-color . "#000000")
> >          (foreground-color . "#ffffff")))
> >      '(inhibit-startup-screen t)
> >     )
> >
> > * init.el:
> >
> >     [EMPTY]
> 
> I'm unable to reproduce this with or without pgtk -- Emacs doesn't flash
> the default background colour on startup, as far as I can tell.  (This
> is on Debian/bookworm with Gnome Shell, if that matters.)

Isn't it true that to have the initial frame appear from the get-go
with some non-default attributes, one must change the X resources?  I
have a vague recollection that this was always like that, and was
never perceived as a problem.  How do you want Emacs to perform the
initialization without first creating a GUI frame, and how can it
create the first GUI frame except with the default attributes?

bug#53232: close 53232

[John Yates]

I apologize for the tone of my most recent note.  My experimenting
was flawed.  When I hide my init.el I failed to delete init.elc.  Once
I deleted it my pgtk build performed as expected.

I have closed the bug.

On Mon, Jan 17, 2022 at 12:37 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> Isn't it true that to have the initial frame appear from the get-go
> with some non-default attributes, one must change the X resources?

In times past I did indeed establish X-resources.  Those are no longer
necessary.  I do not recall when I ditched them.  Perhaps it was around
the advent of early-init.el.

bug#53232: close 53232

[John Yates]