bug#13623: 24.3.50; Redisplay issue with transient-mark-mode

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 06 Feb 2013 19:14:43 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> CC: Eli Zaretskii <eliz@gnu.org>, wence@gmx.li, 13623@debbugs.gnu.org
> 
> I have a few experimental patches with per-frame fonts_changed_p and
> cursor_type_changed flags. Since font/cursor changes are rare, the
> effect is negligible, but this opens the way towards more
> interesting things.

What exactly is the strategy of enabling per-frame redisplay
optimizations?  As you point out, font and cursor type changes are not
the important cost drivers.  The question is: what is?  IOW, how do
you know which changes affect what frames?

The current display engine does not try to optimize per-frame
redisplay (except on a TTY, but let's forget about that for a moment).
It tries to optimize per-window redisplay.  I don't see what's wrong
with this approach; in fact, I think for GUI frames it's better than
per-frame optimizations.  Therefore, I think we should improve
optimizations by more aggressively detecting windows that need not be
updated, instead of turning our attention to frames.

In any case, the first step towards any intelligent improvements in
redisplay optimizations would be to compile a list of use cases where
we currently give up and redisplay entire windows, and where this
thorough redisplay really matters, i.e. we can actually see and
measure the effect of this.

Another area of redisplay optimizations would be the infamous
very-long-lines use case.  (Personally, I think this one is the single
most important deficiency in the current display engine, by far more
important than any other display problem.)