[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to measure frame rate in fps?

From: Dmitry Gutov
Subject: Re: How to measure frame rate in fps?
Date: Tue, 1 Jun 2021 18:00:35 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1

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

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]