bug#52294: 28.0.90; Large delay between clicking tool-bar item and it displaying as depressed

bug#52294: 28.0.90; Large delay between clicking tool-bar item and it displaying as depressed

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Clicking any tab bar button doesn't result in it being immediately
displaying as depressed: instead, you have to move the mouse and wait a
few seconds for it to be displayed that way.

On X-Windows builds without toolkit tool bars, the depressed appearance
is displayed immediately.

In GNU Emacs 28.0.90 (build 1, i686-pc-mingw32)
 of 2021-12-05 built on DESKTOP-IHBUNG7
Windowing system distributor 'Microsoft Corp.', version 10.0.22000
System Description: Microsoft Windows 10 Enterprise (v10.0.2009.22000.318)

Configured using:
 'configure --with-gnutls=ifavailable --prefix=/emacs-28.0.90/../prefix'

Configured features:
ACL MODULES NOTIFY W32NOTIFY PDUMPER SOUND THREADS TOOLKIT_SCROLL_BARS

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1252

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-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
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: 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 rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search seq byte-opt
gv 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 dos-w32 ls-lisp disp-table
term/w32-win w32-win w32-vars 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
hashtable-print-readable backquote threads w32notify w32 multi-tty
make-network-process emacs)

Memory information:
((conses 8 53739 11225)
 (symbols 24 6687 1)
 (strings 16 19706 1714)
 (string-bytes 1 624351)
 (vectors 8 13634)
 (vector-slots 4 183149 16554)
 (floats 8 24 316)
 (intervals 28 318 5)
 (buffers 584 12))

bug#52294: 28.0.90; Large delay between clicking tool-bar item and it displaying as depressed

[Eli Zaretskii]

> Date: Sun, 05 Dec 2021 14:04:09 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> 
> Clicking any tab bar button doesn't result in it being immediately
> displaying as depressed: instead, you have to move the mouse and wait a
> few seconds for it to be displayed that way.

I cannot reproduce that.  Here the reaction is immediate.

Please try to profile Emacs when you press the tab, maybe it will give
some hints.

bug#52294: 28.0.90; Large delay between clicking tool-bar item and it displaying as depressed

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Clicking any tab bar button doesn't result in it being immediately
>> displaying as depressed: instead, you have to move the mouse and wait a
>> few seconds for it to be displayed that way.
>
> I cannot reproduce that.  Here the reaction is immediate.
>
> Please try to profile Emacs when you press the tab, maybe it will give
> some hints.

It's a bit unclear whether this is about the tool bar (mentioned in the
subject) or the tab bar (in the body of the article)...

I can't reproduce this in any case on Debian/bookworm.

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

bug#52294: 28.0.90; Large delay between clicking tool-bar item and it displaying as depressed

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Clicking any tab bar button doesn't result in it being immediately
>>> displaying as depressed: instead, you have to move the mouse and wait a
>>> few seconds for it to be displayed that way.
>>
>> I cannot reproduce that.  Here the reaction is immediate.
>>
>> Please try to profile Emacs when you press the tab, maybe it will give
>> some hints.
>
> It's a bit unclear whether this is about the tool bar (mentioned in the
> subject) or the tab bar (in the body of the article)...

I meant to say toolbar.  Sorry for not reading the report thoroughly
before sending.

> I can't reproduce this in any case on Debian/bookworm.

It only happens on MS-Windows.

bug#52294: 28.0.90; Large delay between clicking tool-bar item and it displaying as depressed

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  52294@debbugs.gnu.org
> Date: Sun, 05 Dec 2021 16:57:56 +0800
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > It's a bit unclear whether this is about the tool bar (mentioned in the
> > subject) or the tab bar (in the body of the article)...
> 
> I meant to say toolbar.  Sorry for not reading the report thoroughly
> before sending.

I cannot reproduce the issue with the tool bar, either.  The reaction
is immediate here.

bug#52294: 28.0.90; Large delay between clicking tool-bar item and it displaying as depressed

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> I cannot reproduce the issue with the tool bar, either.  The reaction
> is immediate here.

FWIW, I don't see the problem on Windows XP, but it's there on every
computer running Windows 10 I tried, and also under Wine.

bug#52294: 28.0.90; Large delay between clicking tool-bar item and it displaying as depressed

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> FWIW, I don't see the problem on Windows XP, but it's there on every
> computer running Windows 10 I tried, and also under Wine.

I tried this in Windows 11 (in a MingW build), and I couldn't reproduce
it:

emacs -Q
Insert some text into *scratch*
Click on the "undo" tool bar item

The "undo" button updates immediately for me.

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

bug#52294: 28.0.90; Large delay between clicking tool-bar item and it displaying as depressed

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> FWIW, I don't see the problem on Windows XP, but it's there on every
>> computer running Windows 10 I tried, and also under Wine.
>
> I tried this in Windows 11 (in a MingW build), and I couldn't reproduce
> it:
>
> emacs -Q
> Insert some text into *scratch*
> Click on the "undo" tool bar item
>
> The "undo" button updates immediately for me.

Was that build 32-bit?

That could perhaps be related.

bug#52294: 28.0.90; Large delay between clicking tool-bar item and it displaying as depressed

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> Was that build 32-bit?
>
> That could perhaps be related.

My build is 64-bit, so perhaps.

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

bug#52294: 28.0.90; Large delay between clicking tool-bar item and it displaying as depressed

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: larsi@gnus.org,  52294@debbugs.gnu.org
> Date: Sun, 05 Dec 2021 17:22:44 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I cannot reproduce the issue with the tool bar, either.  The reaction
> > is immediate here.
> 
> FWIW, I don't see the problem on Windows XP, but it's there on every
> computer running Windows 10 I tried, and also under Wine.

Can you try Emacs 27 on those systems?  I don't currently have Emacs
28 on any Windows 10 box to which I have access, and it doesn't happen
with Emacs 27 there.

bug#52294: 28.0.90; Large delay between clicking tool-bar item and it displaying as depressed

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  52294@debbugs.gnu.org
> Date: Mon, 06 Dec 2021 08:46:41 +0800
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > Po Lu <luangruo@yahoo.com> writes:
> >
> >> FWIW, I don't see the problem on Windows XP, but it's there on every
> >> computer running Windows 10 I tried, and also under Wine.
> >
> > I tried this in Windows 11 (in a MingW build), and I couldn't reproduce
> > it:
> >
> > emacs -Q
> > Insert some text into *scratch*
> > Click on the "undo" tool bar item
> >
> > The "undo" button updates immediately for me.
> 
> Was that build 32-bit?
> 
> That could perhaps be related.

I don't see how this would be related, but all my builds are 32-bit,
FWIW.

bug#52294: 28.0.90; Large delay between clicking tool-bar item and it displaying as depressed

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> Can you try Emacs 27 on those systems?  I don't currently have Emacs
> 28 on any Windows 10 box to which I have access, and it doesn't happen
> with Emacs 27 there.

It works with Emacs 27.2.

bug#52294: 28.0.90; Large delay between clicking tool-bar item and it displaying as depressed

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: larsi@gnus.org,  52294@debbugs.gnu.org
> Date: Mon, 06 Dec 2021 21:26:36 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Can you try Emacs 27 on those systems?  I don't currently have Emacs
> > 28 on any Windows 10 box to which I have access, and it doesn't happen
> > with Emacs 27 there.
> 
> It works with Emacs 27.2.

Which you compiled?  Or someone else?

Anyway, I'm surprised that this could be somehow due to Emacs's code.
The MS-Windows implementation of the tool bar is entirely within
Emacs, so maybe profiling that could give some ideas?