bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time


From: Stefan Monnier
Subject: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time
Date: Wed, 22 Apr 2015 16:52:42 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

> How long is "too long"?  Do you mean that, with
> fast-but-imprecise-scrolling non-nil, jit-lock-defer-time nil, holding
> down C-v, that there is no redisplay for several seconds?

No, it's usually shorter than "several seconds", but it's only refreshed
maybe twice a second (I use a repeat rate of 40/s) with a few waits that
are longer than that.
In contrast with jit-lock-defer-time set to 0, the scrolling is mostly
smooth for me.

> That would be suggesting that the time to scroll one screen (without
> fontification) is longer than your auto-repeat interval, which
> sounds implausible.

It's not the case, indeed, no.
[ Though, if I push the test with a sufficiently tall window (1600
vertical pixels, and a small enough font), I do get it to skip some
redisplays even with font-lock-mode off.  But that's also because my
processor is slow ("Atom-Z530 @ 1.60GHz") and I compile with all kinds
of extra debugging code.  ]

> No, I don't.  ;-)  What I see is somewhat jerky scrolling, mainly
> unfontified, but with some fontification flashing on each screen some
> short time (?10-100 milliseconds) before the next scroll.

Hmm... interesting.  I don't see the "some fontification flashing": for
me it scrolls unfontified until I stop scrolling (at which point it's
shown immediately fontified).
I guess in your case, your machine is just fast enough to perform the
fontification every few steps, whereas mine is always "trying to catch up".

Maybe for you to see the same behavior as I see, you'd have to use
a non-0 setting for jit-lock-defer-time to try and prevent the
occasional deferred fontification (probably using a defer-time that's just
above the repeat-time of your keyboard), but my hack (which basically
disables the deferring when there's no pending input) would need to be
tweaked (it treats timer==0 specially).

> What I see with fast-but-imprecise-scrolling is somewhat jerky scrolling,
> but each displayed screen being fully fontified.

Yes, the always-fontified display is clearly the obvious advantage of
fast-but-imprecise-scrolling.  I'm personally bothered by the jerkiness
of the scrolling, but if jit-lock-defer-time also gives you jerky
scrolling, then clearly it's a loser.

> Also, when I attempt to disable jit-lock-defer-time (through the
> customisation interface) the jit-lock-defer-timer keeps running, and the
> "defer" mechanism keeps running with it.  This seems worth a bug report
> in its own right.

Yup, sounds like it deserves its own bug report.

> I don't understand how what you're seeing is so bad.  I thought you had a
> powerful workstation, a class above a typical PC, and that you had your
> auto-repeat rate at a conservative figure (25 or 30 per second) rather
> than the insane rate (~40 per second) I have.

I have various machines, but my desktops are a Fit-PC2 (at work) and
a AMD E-350 (at home).  So "powerful workstation" is not exactly the
term I would employ.
This said, "insane" is not the term I'd use to describe 40 repetitions
per seconds either.

> I have a 5 year old machine, not a blazingly fast super-modern one,
> and my window is 64 lines deep.

Right windows are typically between 65 and 80 lines tall, as well.


        Stefan





reply via email to

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