GNU bug report logs - #15740
24.3.50; enabling & disabling custom themes is slow

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 15740 in the body.
You can then email your comments to 15740 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: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; enabling & disabling custom themes is slow
Date: Sun, 27 Oct 2013 14:07:30 -0700 (PDT)

Custom themes were presumably inspired from the color themes of library
`color-theme.el'.  Color themes are very quick, however, compared to
custom themes.  You can easily cycle among them, instantaneously, with
no flicker etc.  Not so, custom themes - disabling all enabled themes
and then enabling one theme is painfully slow, and you see all of the
changes manifested on the screen, slowly.  The same is true if there is
only one theme enabled: disabling it and enabling another is very slow.

Is this something that could be fixed?

A custom theme is, I believe, heavier duty, saving more information than
a color theme.  A color theme records frame parameters, faces, and some
variables - no more.

Does this difference in the amount of information account for the
difference in performance?  Dunno.  Hoping someone will take a look...

FYI, color-theme.el is here, and it still works fine with Emacs 24:
http://www.nongnu.org/color-theme.

See also bug #15687: cus-theme.el should provide a means to restore the
initial state, before enabling a theme.


In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-10-19 on LEG570
Bzr revision: 114715 rgm <at> gnu.org-20131019023520-s8mwtib7xcx9e05w
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --enable-checking 'CFLAGS=-O0 -g3' CPPFLAGS=-DGLYPH_DEBUG=1'

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

From: Leo Liu <sdl.web <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15740 <at> debbugs.gnu.org
Subject: Re: bug#15740: 24.3.50; enabling & disabling custom themes is slow
Date: Mon, 28 Oct 2013 09:32:52 +0800

On 2013-10-28 05:07 +0800, Drew Adams wrote:
> Not so, custom themes - disabling all enabled themes
> and then enabling one theme is painfully slow, and you see all of the
> changes manifested on the screen, slowly.  The same is true if there is
> only one theme enabled: disabling it and enabling another is very slow.
>
> Is this something that could be fixed?

But it works splendidly on OS X and GNU/Linux. Do you have a recipe to
see the slowness?

> A custom theme is, I believe, heavier duty, saving more information than
> a color theme.  A color theme records frame parameters, faces, and some
> variables - no more.
>
> Does this difference in the amount of information account for the
> difference in performance?  Dunno.  Hoping someone will take a look...

Many years ago when I tried color-theme it couldn't be cleanly disabled
and at times leave some faces in an unusable state that only a restart
could fix.

Leo

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 15740 <at> debbugs.gnu.org
Subject: RE: bug#15740: 24.3.50; enabling & disabling custom themes is slow
Date: Sun, 27 Oct 2013 20:08:50 -0700 (PDT)

> > Not so, custom themes - disabling all enabled themes
> > and then enabling one theme is painfully slow, and you see all of
> > the changes manifested on the screen, slowly.  The same is true if
> > there is only one theme enabled: disabling it and enabling another
> > is very slow.
> >
> > Is this something that could be fixed?
> 
> But it works splendidly on OS X and GNU/Linux.

Are you sure?  I somehow doubt it.  Have you tried changing themes
when you have multiple frames, say 6 or 10 frames?  Try it.

> Do you have a recipe to see the slowness?

Sure.  `emacs -Q'.  Then load `doremi.el' and `doremi-cmd.el'.  Then use
`M-x doremi-custom-themes+' to cycle among themes.

With the default value of option `doremi-custom-themes-accumulate-flag',
previously enabled themes are disabled when you enable the next one.
But even in that case it is very slow.

If you let the themes accumulate while cycling (toggle that option),
then things get slower and slower and SLOWER, very quickly.  (Makes
sense: you are accumulating more stuff and disabling more stuff.)
I don't really expect cycling with accumulation to be a usable use case
(hence the default value of the option), but someone might want to use
it occasionally to merge a few themes.

And what I described is the case if you have only ONE frame.  If you
have multiple frames then it is much, much slower still.

Compared to what?  Compared to color themes.  The same library
`doremi-cmd.el' gives you command `doremi-color-themes+', for comparison.

Doesn't matter how many frames you have: replacing one *color* theme by
another appears to be instantaneous, and with no flickering (such as you
see with custom themes, where disabling runs through each frame,
redisplaying it, and then the subsequent enabling runs through each
frame again, redisplaying it).

Very simple to compare.  You will need library `color-theme.el',
available here: http://www.nongnu.org/color-theme.

The Do Re Mi files are available on Emacs Wiki:
http://www.emacswiki.org/emacs-en/download/doremi.el
http://www.emacswiki.org/emacs-en/download/doremi-cmd.el

If you want to cycle among themes using some other way than Do Re Mi,
feel free.  You'll see the same thing, I expect.
 
> > A custom theme is, I believe, heavier duty, saving more
> > information than a color theme.  A color theme records frame
> > parameters, faces, and some variables - no more.
> >
> > Does this difference in the amount of information account for the
> > difference in performance?  Dunno.  Hoping someone will take a
> > look...
> 
> Many years ago when I tried color-theme it couldn't be cleanly
> disabled and at times leave some faces in an unusable state that
> only a restart could fix.

What can I say?  Maybe you should try it again, without whatever
else you might have mixed into the bag at the time.

I have never had such a problem with it, including with Emacs 24.

And unlike custom themes, it is trivial to undo most of the effects
of a color theme, i.e., to return to whatever settings you had in
place before applying any theme.

That is apparently not possible with a custom theme - see bug #15687.
All you can do is "disable" a custom theme, which leaves you,
appearance-wise, in the same (_apparently_ themed) state.  OK,
disabling does restore `default-frame-alist` and such, but it does
not update the existing frames to restore their previous appearance.

And it is not just a redisplay thing.  If you have file foo.el in a
frame that has undergone this operation, and you want to see foo.el
in a frame that has the original settings, before you enabled and
disabled a custom theme, then you have to use `C-x 5 2' to open foo.el
in a new frame.  The existing frames are cooked, once and for all.
"Disabling" is only relative to other themes.  It is a far cry from
undoing a theme.

Don't get me wrong.  Custom themes have their strong points - they
have a relatively good Customize interface, and they include more
information than color themes do.  If the bugs get fixed then people
will perhaps rightfully be able to kiss `color-theme.el' goodbye.
Until then, custom themes are unfortunately no substitute for color
themes.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15740 <at> debbugs.gnu.org
Subject: Re: bug#15740: 24.3.50; enabling & disabling custom themes is slow
Date: Thu, 15 Jul 2021 07:40:47 +0200

Drew Adams <drew.adams <at> oracle.com> writes:

> Not so, custom themes - disabling all enabled themes
> and then enabling one theme is painfully slow, and you see all of the
> changes manifested on the screen, slowly.

I tried to reproduce this with

M-x customize-themes RET

and then selecting different themes, and I didn't see any particular
slowness.  Are you still seeing this issue in recent versions of Emacs?

(A theme can contain arbitrary code, of course, so it can be arbitrarily
slow, but that's up to the theme author.)

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

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: "15740 <at> debbugs.gnu.org" <15740 <at> debbugs.gnu.org>
Subject: RE: [External] : Re: bug#15740: 24.3.50; enabling & disabling custom
 themes is slow
Date: Thu, 15 Jul 2021 14:55:23 +0000

> > Not so, custom themes - disabling all enabled themes
> > and then enabling one theme is painfully slow, and you see all of the
> > changes manifested on the screen, slowly.
> 
> I tried to reproduce this with
> 
> M-x customize-themes RET
> 
> and then selecting different themes, and I didn't see any particular
> slowness.  Are you still seeing this issue in recent versions of Emacs?
> 
> (A theme can contain arbitrary code, of course, so it can be arbitrarily
> slow, but that's up to the theme author.)

Yes, the problem is still there.  (Tested, e.g.,
with the latest Emacs release, 27.2.)

See the recipe from emacs -Q in https://arxiv.org/abs/2106.05096

Use C-x 5 2 a few times to get multiple frames.

Set option `doremi-custom-themes-accumulate' to
non-nil.  (That's the _default_ Emacs behavior,
I believe: to accumulate themes, instead of
replacing the last one with the next one.)

Use `M-x doremi-custom-themes+' to cycle among
the themes provided by default (`emacs -Q').

See that same message for how to compare with
color themes.

I'm using MS Windows.  Dunno whether that makes
a difference.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: "15740 <at> debbugs.gnu.org" <15740 <at> debbugs.gnu.org>
Subject: Re: [External] : Re: bug#15740: 24.3.50; enabling & disabling
 custom themes is slow
Date: Thu, 15 Jul 2021 17:00:00 +0200

Drew Adams <drew.adams <at> oracle.com> writes:

> Yes, the problem is still there.  (Tested, e.g.,
> with the latest Emacs release, 27.2.)
>
> See the recipe from emacs -Q in https://arxiv.org/abs/2106.05096

"Multiple simultaneous solution representations in a population based
evolutionary algorithm"?

> Use C-x 5 2 a few times to get multiple frames.
>
> Set option `doremi-custom-themes-accumulate' to
> non-nil.  (That's the _default_ Emacs behavior,
> I believe: to accumulate themes, instead of
> replacing the last one with the next one.)
>
> Use `M-x doremi-custom-themes+' to cycle among
> the themes provided by default (`emacs -Q').

Are you sure that this isn't a problem with doremi?  Do you see the
problem using `M-x customize-themes'?

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

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: "15740 <at> debbugs.gnu.org" <15740 <at> debbugs.gnu.org>
Subject: RE: [External] : Re: bug#15740: 24.3.50; enabling & disabling custom
 themes is slow
Date: Thu, 15 Jul 2021 15:13:28 +0000

> > Yes, the problem is still there.  (Tested, e.g.,
> > with the latest Emacs release, 27.2.)
> >
> > See the recipe from emacs -Q in...
> 
> "Multiple simultaneous solution representations in a 
> population based evolutionary algorithm"?

Oops - copy+paste error.  This is the URL (for msg #11):

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=15740#11

> Are you sure that this isn't a problem with doremi?
> Do you see the problem using `M-x customize-themes'?

Yes - no problem with doremi.  `doremi-custom-themes+'
just changes to the next theme when you hit a key
(e.g. <up>).

And with non-nil option `doremi-custom-themes-accumulate-flag'
it does what Emacs does by default when moving to another
theme: it doesn't cancel the previous theme(s); it just
adds (enables) the new one also (uses `enable-theme').

None of this has anything to do with `customize-themes'.

(The comparison is to use `doremi-color-themes+', which
cycles among _color_ themes.  The code is parallel.)

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: "15740 <at> debbugs.gnu.org" <15740 <at> debbugs.gnu.org>
Subject: Re: [External] : Re: bug#15740: 24.3.50; enabling & disabling
 custom themes is slow
Date: Thu, 15 Jul 2021 17:40:59 +0200

Drew Adams <drew.adams <at> oracle.com> writes:

> And with non-nil option `doremi-custom-themes-accumulate-flag'
> it does what Emacs does by default when moving to another
> theme: it doesn't cancel the previous theme(s); it just
> adds (enables) the new one also (uses `enable-theme').

Ah, I see.  Well, I can see how that can be slow, but it's such a
particular use case that I don't really see us catering towards making
that faster.  So I'm closing this bug report.

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

Previous Next

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