Re: How to measure frame rate in fps?

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 1 Jun 2021 17:18:09 +0300
> 
> On 01.06.2021 14:43, Eli Zaretskii wrote:
> > You just need to remember to include some command that
> > would affect the display, or else redisplay will do very little and
> > redraw nothing.
> 
> Speaking of redisplay redrawing nothing, as long as tool-bar-mode is on, 
> my GTK3 build (with -Q even) evaluates (benchmark 1 '(redisplay)) to a 
> sequence of results like this:
> 
> Elapsed time: 0.040924s
> Elapsed time: 0.026343s
> Elapsed time: 0.023473s
> Elapsed time: 0.025162s
> Elapsed time: 0.030074s
> Elapsed time: 0.041305s (0.026917s in 1 GCs)
> Elapsed time: 0.031169s
> Elapsed time: 0.020957s
> Elapsed time: 0.034885s
> Elapsed time: 0.035338s
> Elapsed time: 0.030864s
> 
> and with tool-bar-mode off:
> 
> Elapsed time: 0.007189s
> Elapsed time: 0.006181s
> Elapsed time: 0.007358s
> Elapsed time: 0.004177s
> Elapsed time: 0.007754s
> Elapsed time: 0.007557s

I know very little about the cost of the GTK tool bar redrawing: the
code is in gtkutil.c, and it's full of GTK API calls.  Maybe the above
times are explained and justified by that, I don't know.

I also am not sure the above faithfully reflects what happens in Real
Life when Emacs has nothing to redisplay: I think you get the tool-bar
redisplay triggered because the evaluation of the benchmark call
causes it somehow.  How did you evaluate it, exactly?

> Not so noticeable if it just happens once, but easily affects the 
> performance of code which performs "virtual" redisplay, such as 
> posn-at-point.

How do you deduce that posn-at-point triggers redisplay of the GTK
tool bar?  It shouldn't, AFAIR.  posn-at-point and its ilk only
simulate display of text, they don't care about window's and frame's
decorations.