Re: How to measure frame rate in fps?

[Dmitry Gutov <dgutov@yandex.ru>]

On 01.06.2021 18:35, Eli Zaretskii wrote:

> Yes, that figures: entering the minibuffer triggers a more thorough
> redisplay than usual: we redisplay the menu bar, the tool bar, and
> several other things as result, for reasons that should be obvious.
> 
> Try C-x C-e instead after typing the sexp in *scratch.  In that
> scenario, I don't expect the tool bar to be redrawn.

Thanks, that's a better methodology.

I still see long-ish redisplays in my "real world" scenario, with 
timings like

Elapsed time: 0.003500s
Elapsed time: 0.026936s
Elapsed time: 0.024454s
Elapsed time: 0.024453s

on redisplay with tool-bar-mode on and

Elapsed time: 0.005239s
Elapsed time: 0.005562s
Elapsed time: 0.014864s
Elapsed time: 0.014525s
Elapsed time: 0.005216s
Elapsed time: 0.014419s
Elapsed time: 0.015004s
Elapsed time: 0.010501s
Elapsed time: 0.013163s

with it off (both measured with 'benchmark-progn' injected in some 
working code), but none of that with 'emacs -Q'.

Perhaps those are to be expected (even though the Emacs frame doesn't 
change much, the scenario involves 1 or 2 network calls).

>>> 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.
>>
>> You're right, posn-at-point shows me different timings. Often enough as
>> high as 12-15ms, which is not great for a low latency display, but the
>> numbers don't seem to be tied to tool-bar-mode being on.
> 
> If you want me to take a look at those 15ms cases, I suggest to file a
> bug report with the details and a recipe.

With updated testing approach, I don't see those timings with 
posn-at-point anymore, thanks.

The only repro I still see is the one described above, in the "complex" 
scenario. Not sure if it's worth reporting, or if the numbers simply 
look correct.