Re: How to measure frame rate in fps?

[Dmitry Gutov]

On 01.06.2021 17:43, Eli Zaretskii wrote:

> 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.

Sometimes the times are high like this, sometimes they are lower. Could 
be it's another GTK bug, and there's nothing we can do, but it's 
probably a bug *somewhere*.

> 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?

Either using M-:, or with M-x benchmark like you suggested (only without 
prefix argument, to measure just 1 iteration). The results are similar.

> > 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.

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.

But we end up calling `redisplay` explicitly on a different code path in 
Company (when a backend talks to an external process, basically), so 
it's still affected by how long that takes.