GNU bug report logs - #53232
29.0.50; pgtk startup: flashes white background before painting black

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 53232 in the body.
You can then email your comments to 53232 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: John Yates <john <at> yates-sheets.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; pgtk startup: flashes white background before painting black
Date: Thu, 13 Jan 2022 11:50:59 -0500

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

Message #8 received at 53232 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: John Yates <john <at> yates-sheets.org>
Cc: 53232 <at> debbugs.gnu.org
Subject: Re: bug#53232: 29.0.50; pgtk startup: flashes white background
 before painting black
Date: Fri, 14 Jan 2022 08:52:45 +0100

John Yates <john <at> 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

Message #13 received at 53232 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 53232 <at> debbugs.gnu.org, john <at> yates-sheets.org
Subject: Re: bug#53232: 29.0.50;
 pgtk startup: flashes white background before painting black
Date: Fri, 14 Jan 2022 13:50:57 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Fri, 14 Jan 2022 08:52:45 +0100
> Cc: 53232 <at> debbugs.gnu.org
> 
> John Yates <john <at> 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.

Message #16 received at 53232 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 53232 <at> debbugs.gnu.org, john <at> yates-sheets.org
Subject: Re: bug#53232: 29.0.50; pgtk startup: flashes white background
 before painting black
Date: Sat, 15 Jan 2022 08:59:37 +0100

Eli Zaretskii <eliz <at> 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

Message #23 received at 53232 <at> debbugs.gnu.org (full text, mbox):

From: John Yates <john <at> yates-sheets.org>
To: 53232 <at> debbugs.gnu.org
Cc: Po Lu <luangruo <at> yahoo.com>
Subject: reopen 53232
Date: Sat, 15 Jan 2022 16:46:56 -0500

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.

Message #28 received at 53232 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: John Yates <john <at> yates-sheets.org>
Cc: Po Lu <luangruo <at> yahoo.com>, 53232 <at> debbugs.gnu.org
Subject: Re: bug#53232: reopen 53232
Date: Mon, 17 Jan 2022 18:24:50 +0100

John Yates <john <at> 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

Message #31 received at 53232 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: luangruo <at> yahoo.com, 53232 <at> debbugs.gnu.org, john <at> yates-sheets.org
Subject: Re: bug#53232: reopen 53232
Date: Mon, 17 Jan 2022 19:37:31 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Mon, 17 Jan 2022 18:24:50 +0100
> Cc: Po Lu <luangruo <at> yahoo.com>, 53232 <at> 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?

Message #34 received at 53232 <at> debbugs.gnu.org (full text, mbox):

From: John Yates <john <at> yates-sheets.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Po Lu <luangruo <at> yahoo.com>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 53232 <at> debbugs.gnu.org
Subject: Re: bug#53232: close 53232
Date: Mon, 17 Jan 2022 15:39:39 -0500

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 <at> 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.

Message #39 received at 53232 <at> debbugs.gnu.org (full text, mbox):

From: John Yates <john <at> yates-sheets.org>
To: 53232 <at> debbugs.gnu.org
Subject: close 53232
Date: Mon, 17 Jan 2022 21:12:53 -0500

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.