Re: How to measure frame rate in fps?

[Eli Zaretskii <eliz@gnu.org>]

> Cc: wyuenho@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 6 Jun 2021 19:48:17 +0300
> 
> On 06.06.2021 15:36, Eli Zaretskii wrote:
> 
> > Then I don't see how this is relevant to the issue with the GTK tool
> > bar making "do-nothing" redisplays more expensive.  The above is a
> > completely different scenario; depending on what exactly was Emacs
> > doing in this scenario, redrawing of the GTK tool bar could indeed
> > account for an insignificant percentage of the CPU time.
> 
> In my scenario the observable window configuration doesn't change 
> between redisplays (though, of course, "current buffer" is switched 
> multiple times under the covers, to send request and parse/receive 
> response), and the values of point (again, during redisplay), are only 1 
> character position apart.

First, that nothing changes on the glass doesn't mean redisplay isn't
working, because it isn't (always) omniscient.

More importantly, I no longer understand what are we discussing.
AFAIU, you have some scenario where Emacs is performing some
non-trivial processing, and where in your opinion redisplay should not
have changed anything on display.  Is that correct?  If so, please
take me from this point and explain what is the issue you see.

> So if there is some caching of the toolbar contents, I don't see why it 
> wouldn't work. I'm also not sure how rendering it can take 10-15 extra 
> milliseconds, but for all I know this could be normal.

The 10-15 milliseconds was measured in a different situation, AFAIU:
an idle "emacs -Q".  Is that correct?

> > And what are you trying to investigate or establish with profiling
> > this scenario?  Maybe I simply don't understand what you wanted to
> > demonstrate.
> 
> That toolbar being enabled has a somewhat unexpected effect on redisplay 
> performance.

I don't think I understand how you conclude this.  I see no traces of
redisplay functions in the profile you have shown.