emacs-devel
[Top][All Lists]
Advanced

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

Re: Is there something like `on-display-functions'?


From: Eli Zaretskii
Subject: Re: Is there something like `on-display-functions'?
Date: Thu, 28 Jan 2010 22:53:52 +0200

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden, address@hidden
> Date: Thu, 28 Jan 2010 14:37:11 -0500
> 
> > If a function on that list needs to be sure it does
> > not miss any text due to the position where a nil-valued `fontified'
> > is placed, it should simply start from some earlier position, not from
> > the one with which it is invoked.  Then it could search for the first
> > position where it needs to do its job, and resume there.
> 
> Which "earlier position"?  How does the function know how far back it
> would need to look?

It could simply record that position in some variable.

> > Note that the JIT Lock function that gets invoked via
> > fontification-functions always starts from the beginning of the line
> > to which the position it was invoked with belongs.  So it is already
> > doing something similar, albeit for different reasons.
> 
> That used to be the case, but now this region-extension has been moved
> to font-lock (where it belongs).

The effect is the same.

> > OTOH, it would be a simple change to have the loop in
> > handle_fontified_prop maintain the lowest buffer position of those
> > where the `fontified' property was placed by any of the functions it
> > invokes, and reset the value of that property to nil for that position
> > after the loop finishes.  Would that resolve the difficulty?
> 
> We could try and solve the problem this way, yes.  Then again, it could
> result in serious inefficiency if one of the functions works on 100B
> chunks and the other on 1KB chunks, forcing the 1KB chunks to be
> recomputed redundantly 10 times.

That would just mean that the 1KB function gets called, detects that
it has nothing to do, and returns.  (Assuming it records its last
chunk in some variable.)

Anyway, in my testing, this inefficiency is not serious.  The bidi
redisplay sometimes needs to traverse the same ``stop point''
(stop_charpos in the iterator structure) several times, first from
left to right, then right to left, etc., because it must do that in
the visual order, and still the display is fast enough to not annoy or
even show a noticeable delay (at least on a machine such as
fencepost)[1].

> This said, I don't think it's a serious problem.  The way I look at it,
> we should have used fontification-function rather than
> fontification-functions, and that's it.
> 
> The "multiplexing" of several functions on this hook can be (and is)
> performed by jit-lock, where it's easier to be more clever (although
> currently jit-lock is not terribly clever either).

Fine with me.  But I do think we may wish to have some more general
redisplay-hook feature, that isn't tailored to fontification.

----------------------
[1] As usual, our mostly wrong impression about the speed of our our
machines stems from the fact that most of the time we see them being
busy moving pixels from here to there.  When time comes to exercise
raw computing power, modern machines are lightning fast.

A case in point is the bidi reordering code.  Its processing core is
no less than 1500 lines of C, which replace these two lines in the
current unidirectional display engine:

          IT_BYTEPOS (*it) += it->len;
          IT_CHARPOS (*it) += 1;

(For those who are not familiar with the display engine, this advances
the iterator by one character and the corresponding number of bytes,
as determined by the length of its multibyte sequence.)

IOW, instead of two increments, we run a 1500-line monster.  Mind you,
this runs in the innermost loop of the display engine!  Would you be
surprised to know that I got scared when I finished implementing the
reordering code?  I was afraid that the resulting redisplay will
crawl.  So I timed the code, by writing a trivial wc workalike, and
timing it against the real wc.  To my surprise it worked at half the
speed of wc, which is pretty darn fast, concerning what it needs to
do instead of just incrementing a pointer.

Morale: never underestimate what a modern CPU can do when it does not
need to move pixels ;-)




reply via email to

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