[Top][All Lists]

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

Re: Scrolling commands and skipping redisplay, was: Re: emacs rendering

From: Dmitry Gutov
Subject: Re: Scrolling commands and skipping redisplay, was: Re: emacs rendering comparisson between emacs23 and emacs26.3
Date: Fri, 10 Apr 2020 01:17:51 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

Hi Eli,

You have addressed only about 30% of my previous email.

I'll have refer to the remaining 70% anyway.

On 09.04.2020 10:46, Eli Zaretskii wrote:
In my testing with an '-Og -g3' build (from emacs-27; master is much
faster with the recent tweaks) it allows for redisplay once every
several screenfuls or so. So it seems like a good tradeoff, in those
particular conditions.

Tradeoffs of what?  You are probably scrolling in a buffer that uses
a single font all over, with fontifications changing only the colors.
While this is a very frequent scenario, it is by no means the only one
Emacs needs to support.  Imagine a buffer where many lines have
characters that become much taller than the default after
fontifications -- in such a buffer fast-but-imprecise-scrolling will
cause you get to the wrong screenful, because it will consider each
character to be displayed with the default face.

You will have the wrong screenful, yes. But how wrong exactly? If the user floored C-v, they are not looking for precision. That's my main justification for the approach (a) presented in that last patch, and it's the aspect that the said patch improves: instead of having imprecise scrolling always, they only have that when input arrives too fast.

-  if (whole && Vfast_but_imprecise_scrolling)
+  if (whole && input_was_pending)
      specbind (Qfontification_functions, Qnil);

I don't like this, because it's unconditional.  In my view, the
tradeoff proposed by fast-but-imprecise-scrolling is a bad tradeoff,
something I personally will never take, even if Emacs locks up for
many seconds in some situation.  If you suggest to _add_ the
pending-input condition to fast-but-imprecise-scrolling being set,
then I'm okay with that optional behavior being smarter (assuming this
doesn't have downsides we aren't aware of yet), if users of
fast-but-imprecise-scrolling agree with it.

These are all rough patches. I'm more interested in a discussion than in a rubber-stamp. And I'd be surprised if fast-but-imprecise-scrolling has a significant number of users yet.

More generally, I don't think I see how even this proposal makes
something clearly better.

There were two different proposals in that email. And one general feature request.

That patch was for (a). I'm inclined to prefer (b), even though the implementation is dirtier. See attached patch that switches between (a) and (b) based on the value of fast-but-imprecise-scrolling. The (b) behavior becomes the default.

Curiously, I think that this patch demonstrates that while fast-but-imprecise-scrolling makes scrolling faster (a), the result looks less responsive than the (new) default behavior (b). And that one looks more responsive than the current one.

Neither of them deals with the backed-up input queue, alas (#2).

We already have jit-lock-defer-time; people
who have slow machines are advised to set that to something like 0.1
or 0.25, and they can have scrolling that is way faster than with
fast-but-imprecise-scrolling (and with the same tradeoff of making
scrolling "imprecise").  Why invent kludges when we already have a
better solution that was there since Emacs 21?

As explained in a separate subthread, jit-lock-defer-time=0 has worse side-effects than fast-but-imprecise-scrolling (while including its downside). And I won't even mention values higher than 0.

But, of course, if we can make jit-lock-defer-time=0 non-flickery, we could recommend that instead of fast-but-imprecise-scrolling=t.

Attachment: more_responsive_scrolling.diff
Description: Text Data

reply via email to

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