Re: Emacs GTK scroll-bar flickering

[Miles Bader <miles@lsi.nec.co.jp>]

Hi,

"Jan D." <jan.h.d@swipnet.se> writes:
> I made some changes, please try them out.

I tried today's CVS; it's a bit hard to tell -- maybe the number of
full-redraws on each buffer change is less, but the overall feel is
roughly the same (painful).

> There are some of the redraws that can't easily be eliminated.  GDK
> (the layer under GTK) does its own event buffering, and releases the
> events when the GTK event loop is entered and there are no events to
> process.  Since Emacs are not using a pure GTK loop, there might be a
> very long time before GTK gets a chance to notice this.  So Emacs must
> force out these events.  Ideally they should not generate any more
> redraws, just make them happen earlier, but experience shows that we
> do get redraws.

The thing is that it's not just that emacs redraws _more_ than GTK apps,
it's that it redraws _at all_ (by `redraw' here, I'm referring to full
redraws).  IOW, it's a `0 vs 1' problem, not a `1 vs 2' problem.

Gedit, for instance, simply doesn't appear to `redraw' the scrollbar at
all when it moves, it simply updates the bar position with no apparent
change to the rest of the scrollbar; visually, it doesn't draw much
attention.  Emacs, on the other hand, seems to clear the whole scrollbar
and redraw everything (the thumb and arrow buttons are the most obvious)
for ever single update.  This full redrawing is _very_ distracting; not
only does it slow down emacs redisplay (a lot -- scrolling by holding
down a key is very painful), it constantly draws attention to the
scrollbar, even when the actual change in the buffer is extremely tiny.

Most mystifying...

Thanks,

-Miles
-- 
Would you like fries with that?