Emacs GTK scroll-bar flickering

Emacs GTK scroll-bar flickering

[Miles Bader]

Hi,

I decided to check out emacs' GTK support again today, and notice that
while it's mostly working great, the scrollbars flicker madly, to the
point where I find I can't use them (simply because the flickering is
too annoying).

They flicker not only when being used, but apparently for any redisplay
that happens, no matter how small (e.g., insert a character at the end
of the buffer, and the scrollbars will flicker), and indeed, flicker
quite a bit even if you're doing nothing!

I can't really tell exactly what's happening, but it looks like it's
simply redrawing the whole scrollbar at every opportunity.

I tried to use as standard an environment as possible, e.g., `emacs -q',
no .gtkrc-2.0 file, no X resources.  The flicker is even more noticable
with pixmap themes, presumably because they're slower to draw, and
often use more contrast.  It's a debian-unstable system, which

Is this a known problem?  Is it solvable?  I don't see anything like
this with other GTK apps, so I guess it must be emacs.

BTW, libgtk is version 2.2.1, emacs is today's CVS.

Thanks,

-Miles
-- 
We live, as we dream -- alone....

Re: Emacs GTK scroll-bar flickering

[Kai Großjohann]

Miles Bader <miles@lsi.nec.co.jp> writes:

> I decided to check out emacs' GTK support again today, and notice that
> while it's mostly working great, the scrollbars flicker madly, to the
> point where I find I can't use them (simply because the flickering is
> too annoying).

I don't see a lot of flickering with the GTK scrollbars.

It is the case that the whole Emacs window (frame) goes blank at
times, only to come back with the right contents 0.5 seconds (or so)
later.  I don't recall at the moment when it happens.

I tried your test of adding something to the end of a buffer, but
don't see anything.
-- 
A preposition is not a good thing to end a sentence with.

Re: Emacs GTK scroll-bar flickering

[Andreas Schwab]

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:

|> Miles Bader <miles@lsi.nec.co.jp> writes:
|> 
|> > I decided to check out emacs' GTK support again today, and notice that
|> > while it's mostly working great, the scrollbars flicker madly, to the
|> > point where I find I can't use them (simply because the flickering is
|> > too annoying).

I see that, too.

|> I tried your test of adding something to the end of a buffer, but
|> don't see anything.

Just holding down return is enough for me to see it.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Emacs GTK scroll-bar flickering

[Kai Großjohann]

Andreas Schwab <schwab@suse.de> writes:

> Just holding down return is enough for me to see it.

Maybe I'm blind or something...
-- 
A preposition is not a good thing to end a sentence with.

Re: Emacs GTK scroll-bar flickering

[Miles Bader]

On Fri, Mar 14, 2003 at 01:44:49PM +0100, Kai Gro?johann wrote:
> Maybe I'm blind or something...

I suspect that you're probably just using a GTK theme where it's less
noticable; I use a pixmap theme (i.e., a bit slow to draw) with a lot of
contrasty bits, which makes the flicker _very_ obvious.  With other themes
(e.g. the default), it's not as obvious, but I can see that it's still
happening.  Also, I suppose it may be related to the GTK version, etc.

BTW, it's not just inserting characters at the end of the buffer that does
it, it's essentially _every single command_ (it even flickers if you just let
it sit there and do nothing!).

-Miles
-- 
Freedom's just another word, for nothing left to lose   --Janis Joplin

Re: Emacs GTK scroll-bar flickering

[Jan D.]

Miles Bader wrote:
> On Fri, Mar 14, 2003 at 01:44:49PM +0100, Kai Gro?johann wrote:
> 
>>Maybe I'm blind or something...
> 
> 
> I suspect that you're probably just using a GTK theme where it's less
> noticable; I use a pixmap theme (i.e., a bit slow to draw) with a lot of
> contrasty bits, which makes the flicker _very_ obvious.  With other themes
> (e.g. the default), it's not as obvious, but I can see that it's still
> happening.  Also, I suppose it may be related to the GTK version, etc.
> 
> BTW, it's not just inserting characters at the end of the buffer that does
> it, it's essentially _every single command_ (it even flickers if you just let
> it sit there and do nothing!).

Internally in Emacs x_set_toolkit_scroll_bar_thumb gets called a lot, for 
example when the cursor moves.  One would think it should only be called when 
needed (i.e. anithing changed scrollbar-wise).  This coupled with the fact that 
scroll bar redraws in GTK seems to be particulary bad, makes the flicker 
happen.  I can just see it when opening a large file and pressing down arrow so 
the cursor goes from top to bottom rapidly.  I do not have a pixmap theme either.

I am reluctant to change how  x_set_toolkit_scroll_bar_thumb gets called as it 
might break something, so I added a fix for GTK instead.  Please try it. 
Scroll bar redraws have been a problem the whole time, for example, getting it 
to redraw when moving the scroll bar from the left to the right, getting it to 
clear the background (i.e. behind the thumb) when splitting a window, etc.

	Jan D.

Re: Emacs GTK scroll-bar flickering

[Stefan Monnier]

> I am reluctant to change how  x_set_toolkit_scroll_bar_thumb gets called as
> it might break something, so I added a fix for GTK instead.  Please try it.

I understand your concerns, but I think it would be better if the
fix applied to all GUIs rather than just to GTK.  Unless the problem
is that the toolkits themselves should optimize such redraws,
of course.


	Stefan

Re: Emacs GTK scroll-bar flickering

[Jan D.]

fredagen den 14 mars 2003 kl 21.04 skrev Stefan Monnier:

>> I am reluctant to change how  x_set_toolkit_scroll_bar_thumb gets called 
>> as
>> it might break something, so I added a fix for GTK instead.  Please try 
>> it.
>
> I understand your concerns, but I think it would be better if the
> fix applied to all GUIs rather than just to GTK.  Unless the problem
> is that the toolkits themselves should optimize such redraws,
> of course.

Well, I don't know how it is supposed to work.  Can anyone explain?

	Jan D.

Re: Emacs GTK scroll-bar flickering

[Miles Bader]

Hmmm, today's CVS seems _slightly_ better -- at least, cursor movement
doesn't cause flickering.  However, the behavior when the buffer size
(or window configuration, etc) changes is if anything, worse now: it
looks like whenever the scrollbar gets updated (even by a single
character change in the buffer), it's getting completely cleared and
redrawn about 4 or 5 times, with each redraw being very obvious and slow
(this is certainly exacerbated because I'm using a pixmap theme, but
this theme is not a problem with other GTK apps).

Something really seems drastically wrong here, since other GTK apps [I'm
using `gedit' for comparison] have basically no flickering, slowdown, or
obviously excessive redraws when they update the scrollbar.  It seems as
if emacs is somehow completely regenerating the scrollbar whereas other
apps are using some sort of interface that allows incremental updating
or the like.

-Miles
-- 
自らを空にして、心を開く時、道は開かれる

Re: Emacs GTK scroll-bar flickering

[Jan D.]

Miles Bader wrote:
> Hmmm, today's CVS seems _slightly_ better -- at least, cursor movement
> doesn't cause flickering.  However, the behavior when the buffer size
> (or window configuration, etc) changes is if anything, worse now: it
> looks like whenever the scrollbar gets updated (even by a single
> character change in the buffer), it's getting completely cleared and
> redrawn about 4 or 5 times, with each redraw being very obvious and slow
> (this is certainly exacerbated because I'm using a pixmap theme, but
> this theme is not a problem with other GTK apps).
> 
> Something really seems drastically wrong here, since other GTK apps [I'm
> using `gedit' for comparison] have basically no flickering, slowdown, or
> obviously excessive redraws when they update the scrollbar.  It seems as
> if emacs is somehow completely regenerating the scrollbar whereas other
> apps are using some sort of interface that allows incremental updating
> or the like.


I made some changes, please try them out.

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.

	Jan D.

Re: Emacs GTK scroll-bar flickering

[Miles Bader]

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?

Re: Emacs GTK scroll-bar flickering

[Jan D.]

>
> 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).

You must have a very complicated theme or a very slow machine, I can't
see this at all.  Are you sure you updated CVS?

>> 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.

Emacs does not "redraw" the scroll bars ever, it just tells GTK what values
to use for the scroll bars.  The desicion to redraw is in GTK entirely.
GTK redraws scroll bars by clearing all and then redraw, which is very
primitive.  Emacs probably changes thumb much more than Gedit, as Gedit
counts lines visible, but Emacs counts characters.  But a good scroll bar
should be able to handle this, as indeed Motif, Xaw3d and others do.

	Jan D.

Re: Emacs GTK scroll-bar flickering

[Miles Bader]

"Jan D." <jan.h.d@swipnet.se> writes:
> > 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).
> 
> You must have a very complicated theme or a very slow machine, I can't
> see this at all.

I think my usual theme is slower than most, but this effect happens even
with the default Gnome theme; one standard theme that seems to show it
pretty well is the `Crux' theme (this is available as a package in
Debian, I'm not sure about other distros).  The `Geramik' theme shows
the effect even better, but I think it's less common(?).

My machine is a fairly standard current PC-type (1GHz PIII, 256MB RAM,
I810 MB/graphics chipset, running XFree86 4.2.1, libgtk 2.2.1).

> Are you sure you updated CVS?

Yup; I tried another `cvs update' just now to make sure, and everything
seems up-to-date.

> Emacs does not "redraw" the scroll bars ever, it just tells GTK what
> values to use for the scroll bars.  The desicion to redraw is in GTK
> entirely.  GTK redraws scroll bars by clearing all and then redraw,
> which is very primitive.

Hmmm, then maybe something is wrong with GTK then, or somehow it's
getting confused by emacs; perhaps it's my GTK installation (standard
Debian unstable)?

> Emacs probably changes thumb much more than Gedit, as Gedit counts
> lines visible, but Emacs counts characters.

That's not the issue, I think -- with exactly the same file and theme,
I can drag the scrollbar around in Gedit with _no_ flickering or other
unpleasant artifacts, whereas emacs flickers like crazy in the same test.

Here's an attempt to be a bit more specific about a case wehre I'm
seeing the problem:

 (1) Somehow pick the Crux GTK theme; the problem will show up with the
     default theme too, but less noticably.

     I think one thing that makes the Crux theme a good test that it has
     a fairly strong contrast between the color of the scrollbar thumb
     and the color of the trough -- so complete redraws become pretty
     obvious (because they draw the trough and then the thumb on top).

 (2) Do:
        xrdb < /dev/null        # or rename .Xdefaults if you use that
        emacs -q &

 (3) OK, now you should see the scratch buffer, with the standard 3-line
     comment at the beginning.  Go to the end of the buffer, and start
     typing random characters.

 (4) The result I see is:

    (a) Until your typing reaches the end of the line, the scrollbar is
        quite stable, with no obvious flickering.

    (b) When the typing reaches the end of the line, and continues onto
        the next line, the scrollbar starts flickering obviously, and
        will continue as you type.

        [Note that the flickering happens in other situations too, not
        just line-wrapping cases; however, this one is particularly
        easy to reproduce.]
 
        BTW, another odd thing: in the initial scratch-buffer, the
        scrollbar thumb doesn't extend all the way to the top and the
        bottom of the scrollbar, even though the entire is clearly
        visible.

I hope this can help a bit...

-miles
-- 
Suburbia: where they tear out the trees and then name streets after them.

Re: Emacs GTK scroll-bar flickering

[Luc Teirlinck]

Miles Bader wrote:

   Yup; I tried another `cvs update' just now to make sure, and everything
   seems up-to-date.

You were able to do `cvs update' despite the current savannah hardware
problems?

Sincerely,

Luc.

Re: Emacs GTK scroll-bar flickering

[Miles Bader]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:
> You were able to do `cvs update' despite the current savannah hardware
> problems?

Yup.  FWIW, I'm updating from `subversions.gnu.org:/cvsroot/emacs'.

-Miles
-- 
Next to fried food, the South has suffered most from oratory.
  			-- Walter Hines Page

Re: Emacs GTK scroll-bar flickering

[Luc Teirlinck]

Miles Bader wrote:

   Yup.  FWIW, I'm updating from `subversions.gnu.org:/cvsroot/emacs'.

Strange.  I am getting:

cvs [login aborted]: recv() from server subversions.gnu.org: EOF

Other people reported similar problems and Mathieu Roy confirmed that
there are hardware problems.

Sincerely,

Luc.

Re: Emacs GTK scroll-bar flickering

[Miles Bader]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:
>    Yup.  FWIW, I'm updating from `subversions.gnu.org:/cvsroot/emacs'.
> 
> Strange.  I am getting:
> 
> cvs [login aborted]: recv() from server subversions.gnu.org: EOF

I'm also using a non-standard port for the CVS server (port 443), for
firewall reasons, but doing so requires a modified CVS client or some
other trickery.

-Miles
-- 
Suburbia: where they tear out the trees and then name streets after them.

Re: Emacs GTK scroll-bar flickering

[Miles Bader]

I wrote:
> I'm also using a non-standard port for the CVS server (port 443), for
> firewall reasons, but doing so requires a modified CVS client or some
> other trickery.

Hmmm, actually, while the fire-wall stuff requires trickery, I think you
should be able to try the alternative port using a normal CVS client...

-Miles
-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.

Re: Emacs GTK scroll-bar flickering

[Jan D.]

> > Emacs probably changes thumb much more than Gedit, as Gedit counts
> > lines visible, but Emacs counts characters.
> 
> That's not the issue, I think -- with exactly the same file and theme,
> I can drag the scrollbar around in Gedit with _no_ flickering or other
> unpleasant artifacts, whereas emacs flickers like crazy in the same test.

It indeed is the issue.  Where Gedit counts the lines in a file and
the lines shown, Emacs counts characters.

When calculating the size of the thumb, one basically divide lines shown
with total lines in file.  When moving about and adding or
deleting characters that does not change the number of lines in the
file, the thumb size does not change.

When lines aren't available, Emacs uses characters instead.  But
every character added or deleted changes the thumb because the ratio
between total number characters in the file and the number of characters
shown changes.  Thus, Emacs updates the thumb a lot more than a
line based application.  When the scroll bar is bad at updating
for small changes like this, flicker occurs.

> Here's an attempt to be a bit more specific about a case wehre I'm
> seeing the problem:
> 

 [deleted]

Thanks for this test case.  I can see redraws here.  They all come from
the fact that Emacs updates the thumb often.  This is basically a
GTK problem.  Perhaps we can find some way to not update the thumb
so often.


>  (4) The result I see is:
> 
>     (a) Until your typing reaches the end of the line, the scrollbar is
>         quite stable, with no obvious flickering.
> 
>     (b) When the typing reaches the end of the line, and continues onto
>         the next line, the scrollbar starts flickering obviously, and
>         will continue as you type.

For every character you type, Emacs updates the thumb.
Why it does not do that for the first line must have something to do with
the redraw engine.  It happens for all toolkits.
It is even more noticable if you insert some lines of characters by
holding down a letter and then delete them all by holding down DEL.

>         BTW, another odd thing: in the initial scratch-buffer, the
>         scrollbar thumb doesn't extend all the way to the top and the
>         bottom of the scrollbar, even though the entire is clearly
>         visible.

This is by design.  It is so you can scroll with the scroll bar so the
last line of the buffer is at the top of the frame.

	Jan D.

Re: Emacs GTK scroll-bar flickering

[Kevin Rodgers]

Jan D. wrote:

>Miles Bader writes:
>>That's not the issue, I think -- with exactly the same file and theme,
>>I can drag the scrollbar around in Gedit with _no_ flickering or other
>>unpleasant artifacts, whereas emacs flickers like crazy in the same test.
> 
> It indeed is the issue.  Where Gedit counts the lines in a file and
> the lines shown, Emacs counts characters.
> 
> When calculating the size of the thumb, one basically divide lines shown
> with total lines in file.  When moving about and adding or
> deleting characters that does not change the number of lines in the
> file, the thumb size does not change.
> 
> When lines aren't available, Emacs uses characters instead.  But
> every character added or deleted changes the thumb because the ratio
> between total number characters in the file and the number of characters
> shown changes.  Thus, Emacs updates the thumb a lot more than a
> line based application.  When the scroll bar is bad at updating
> for small changes like this, flicker occurs.

What does that mean, "when lines aren't available"?


Since scrolling is about vertical display, the only thing that counts is the
number of lines of text (or the number of pixels, in case of variable height
fonts and/or images).  The number of characters is irrelevant.

-- 
<a href="mailto:&lt;kevin.rodgers&#64;ihs.com&gt;">Kevin Rodgers</a>

Re: Emacs GTK scroll-bar flickering

[Miles Bader]

On Tue, Mar 18, 2003 at 11:15:04PM +0100, Jan D. wrote:
> > That's not the issue, I think -- with exactly the same file and theme,
> > I can drag the scrollbar around in Gedit with _no_ flickering or other
> > unpleasant artifacts, whereas emacs flickers like crazy in the same test.
> 
> It indeed is the issue.  Where Gedit counts the lines in a file and
> the lines shown, Emacs counts characters.
...
> Thus, Emacs updates the thumb a lot more than a
> line based application.  When the scroll bar is bad at updating
> for small changes like this, flicker occurs.

I'm completely confused by your reasoning here.  I agree that emacs will
update the thumb more _often_ because of the lines vs. characters thing, but
what I was trying to say is that _even when_ the scrollbar gets updated in
(e.g.) gedit, it doesn't `flicker' (that is, it is redrawn with no obvious
visual clutter), whereas when a similar update happens in emacs, it _does_
flicker (the redraw, even for small changes, is very obvious).  IOW, for a
_single_ change-the-scroll-bar event, gedit's scrollbar will be updated
nicely, but emacs' will be updated distractingly.

I'd think that as far as the scrollbar code is concerned, the two cases
should be the same -- after all, the scrollbar is going to get a bunch of
numbers, and not know what they correspond to.

One case I can think of that might cause a difference is if the GTK scrollbar
code were bad at dealing with changes in total size of the range (which would
change every time you typed a character in emacs, but only when you type a
new line in gedit).  However, the emacs flicker can happen even in cases
where nothing changes, for instance, I can make it happen just by dragging
the scrollbar thumb around.

Is there something about the particular pattern of numbers that emacs feeds
to the scrollbar that confuses it?  Do you have a handle on exactly what it
is?  [If nothing else, I'd like to send a bug report to the GTK people...]

Thanks,

-Miles
-- 
`Cars give people wonderful freedom and increase their opportunities.
 But they also destroy the environment, to an extent so drastic that
 they kill all social life' (from _A Pattern Language_)

Re: Emacs GTK scroll-bar flickering

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> Is there something about the particular pattern of numbers that emacs feeds
> to the scrollbar that confuses it?  Do you have a handle on exactly what it
> is?  [If nothing else, I'd like to send a bug report to the GTK people...]

Maybe the size of the thumb changes more often with emacs.  IIRC,
emacs calculates the thumb size based on the #(characters in the
window) / #(characters in the file) ratio, so just dragging the
cursor may change the size of the thumb.

If GTK repaints the entire scroll bar when the thumb size changes,
maybe that could explain the flicker.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Emacs GTK scroll-bar flickering

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> Maybe the size of the thumb changes more often with emacs.  IIRC,
> emacs calculates the thumb size based on the #(characters in the
> window) / #(characters in the file) ratio, so just dragging the
> cursor may change the size of the thumb.
> 
> If GTK repaints the entire scroll bar when the thumb size changes,
> maybe that could explain the flicker.

I don't think that's it, or at least not entirely it, for several
reasons:

 (1) If I create a file containing a large number of identical lines,
     then scrolling in emacs shouldn't change the thumb size, as long as
     I don't get near the end of the file.  Nevertheless, dragging the
     scrollbar in emacs flickers noticeably.  My test file, BTW is 68
     lines of the following:

        alskdfjlaskdjfalskdjfalskfjlaskdfjalskfjdaskldfj

 (2) Gedit's scrollbar doesn't flicker _at all_ when the thumb-size
     changes.  I tested this by taking the above file, copying a bunch
     of lines from it, and then pasting into the end of the gedit
     buffer, while carefully watching the scrollbar end-buttons (which
     are one of the most obvious `flicker points' in emacs); the result
     was that the thumb shrank quite bit with a few pastes, but the
     scrollbar update was rock-stable, no flicker at all.

     It could be, of course, that gedit has some sort of additional
     graphic optimization to prevent flicker since it uses GTK for all
     its display.

-Miles
-- 
Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.

Re: Emacs GTK scroll-bar flickering

[Jan D.]

>> When lines aren't available, Emacs uses characters instead.  But
>> every character added or deleted changes the thumb because the ratio
>> between total number characters in the file and the number of characters
>> shown changes.  Thus, Emacs updates the thumb a lot more than a
>> line based application.  When the scroll bar is bad at updating
>> for small changes like this, flicker occurs.
>
> What does that mean, "when lines aren't available"?

It means that the code that updates the scroll bar does not have that
information.


> Since scrolling is about vertical display, the only thing that counts is 
> the
> number of lines of text (or the number of pixels, in case of variable 
> height
> fonts and/or images).  The number of characters is irrelevant.

Yes, but this is not the way Emacs works.  It does not keep track of
the number of lines in a buffer unless you tell it to (line-number-mode).

	Jan D.

Re: Emacs GTK scroll-bar flickering

[Richard Stallman]

cvs update is working for me too.

Re: Emacs GTK scroll-bar flickering

[Jan D.]

> storm@cua.dk (Kim F. Storm) writes:
> > Maybe the size of the thumb changes more often with emacs.  IIRC,
> > emacs calculates the thumb size based on the #(characters in the
> > window) / #(characters in the file) ratio, so just dragging the
> > cursor may change the size of the thumb.
> > 
> > If GTK repaints the entire scroll bar when the thumb size changes,
> > maybe that could explain the flicker.
> 
> I don't think that's it, or at least not entirely it, for several
> reasons:
> 

The issues below are due to the other problem I already mentioned,
Emacs does not use a pure GTK event loop.  For example, redraws
are done in an "idle" event handler.  But since Emacs may not call
the event loop when it is idle, redraws must be forced as they happen.

GTK does double buffering in the "idle" redraw handler.  This
double buffering is not done when we push out redraws, it seems.

So Gedit has double buffering, Emacs has not.  This is a huge difference
and explains why the scroll bars in GTK can "get away" with a sloppy
redraw strategy (i.e. clear all and redraw).

When dragging, Emacs exits the GTK event loop and goes back to its
own loop.  Then when an X event comes, it reenters the GTK event loop
until all X events has been processed, then exits and enters again, etc.
All this exiting and entering also seems to defeat the double buffering.

I am trying to figure out a way for Emacs to handle this better.

BTW, the GTK version in CVS has some serious redraw problems when
changing scroll bars, they can even dissappear (C-l should get
them back).  It may be a while before it gets fixed.

	Jan D.

>  (1) If I create a file containing a large number of identical lines,
>      then scrolling in emacs shouldn't change the thumb size, as long as
>      I don't get near the end of the file.  Nevertheless, dragging the
>      scrollbar in emacs flickers noticeably.  My test file, BTW is 68
>      lines of the following:
> 
>         alskdfjlaskdjfalskdjfalskfjlaskdfjalskfjdaskldfj
> 
>  (2) Gedit's scrollbar doesn't flicker _at all_ when the thumb-size
>      changes.  I tested this by taking the above file, copying a bunch
>      of lines from it, and then pasting into the end of the gedit
>      buffer, while carefully watching the scrollbar end-buttons (which
>      are one of the most obvious `flicker points' in emacs); the result
>      was that the thumb shrank quite bit with a few pastes, but the
>      scrollbar update was rock-stable, no flicker at all.
> 
>      It could be, of course, that gedit has some sort of additional
>      graphic optimization to prevent flicker since it uses GTK for all
>      its display.

Re: Emacs GTK scroll-bar flickering

[Miles Bader]

"Jan D." <jan.h.d@swipnet.se> writes:
> So Gedit has double buffering, Emacs has not.  This is a huge difference
> and explains why the scroll bars in GTK can "get away" with a sloppy
> redraw strategy (i.e. clear all and redraw).

Hmm, that makes sense.

Perhaps GTK needs some way to say `suspend the (GTK) event loop, but
allow it to be resumed later as if nothing changed' (with some other
function that you can call to tell it `something's actually changed').

-Miles
-- 
"I distrust a research person who is always obviously busy on a task."
   --Robert Frosch, VP, GM Research

Re: Emacs GTK scroll-bar flickering

[Richard Stallman]

    When lines aren't available, Emacs uses characters instead.  But
    every character added or deleted changes the thumb because the ratio
    between total number characters in the file and the number of characters
    shown changes.  Thus, Emacs updates the thumb a lot more than a
    line based application.  When the scroll bar is bad at updating
    for small changes like this, flicker occurs.

If the cause is really that, perhaps Emacs should remember the last
size and position values used for the scroll bar, and report them to
GTK instead of the real values, as long as the real size and position
have not changed by more than 1% from those saved values.

Re: Emacs GTK scroll-bar flickering

[Richard Stallman]

    When dragging, Emacs exits the GTK event loop and goes back to its
    own loop.  Then when an X event comes, it reenters the GTK event loop
    until all X events has been processed, then exits and enters again, etc.
    All this exiting and entering also seems to defeat the double buffering.

Perhaps GTK needs to be changed to do its double buffering
even between one call to its event loop and the next.

Re: Emacs GTK scroll-bar flickering

[Jan D.]

Richard Stallman wrote:
>     When dragging, Emacs exits the GTK event loop and goes back to its
>     own loop.  Then when an X event comes, it reenters the GTK event loop
>     until all X events has been processed, then exits and enters again, etc.
>     All this exiting and entering also seems to defeat the double buffering.
> 
> Perhaps GTK needs to be changed to do its double buffering
> even between one call to its event loop and the next.

Actually it does, I didn't see the correct reason for double buffering not 
working.  It turns out that since the container widget Emacs uses isn't double 
buffered, all the children (scroll bars) does not get double buffering either.

I have checked in a fix for this (actually a couple a days ago, but it was 
incomplete), hopefully it finally fixes this problem (hey, one can hope :-).

	Jan D.

Re: Emacs GTK scroll-bar flickering

[Miles Bader]

"Jan D." <jan.h.d@swipnet.se> writes:
> It turns out that since the container widget Emacs uses isn't double
> buffered, all the children (scroll bars) does not get double buffering
> either.
> 
> I have checked in a fix for this (actually a couple a days ago, but it was 
> incomplete), hopefully it finally fixes this problem (hey, one can hope :-).

Yes, this seems to have fixed the flickering problem completely
(there are still some rough updates when the emacs window configuration
changes, but that's a relatively rare event, and I guess this sort of
thing is probably never going to be perfect, given that GTK is somewhat
bolted onto emacs).

Thanks for fixing it (and for putting up with all my complaining)!

BTW, I find that I can get better scrolling behavior with emacs/GTK if I
set `redisplay-dont-pause' to t -- otherwise, if I e.g., hold down a
scroll key (say C-v), scrolling updates the scroll bar smoothly, but the
text window only gets updated when I stop scrolling.  Any comment on
this?  [My processor seems to be fast enough to keep up when
redisplay-dont-pause is t]

-Miles
-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.

Re: Emacs GTK scroll-bar flickering

[Miles Bader]

I wrote:
> I find that I can get better scrolling behavior with emacs/GTK if I
> set `redisplay-dont-pause' to t -- otherwise, if I e.g., hold down a
> scroll key (say C-v), scrolling updates the scroll bar smoothly, but
> the text window only gets updated when I stop scrolling.

This again seems to be related to the fact that my GTK theme is very
slow to draw -- if I switch to a more svelte theme, redisplay during
scrolling is `normal' regardless of the setting of redisplay-dont-pause.

I guess that even thought it seems fast enough, the theme uses enough
CPU drawing itself that emacs gets confused and suppresses the text
redisplay during scrolling.

-Miles
-- 
I'd rather be consing.

Re: Emacs GTK scroll-bar flickering

[Jan D.]

> "Jan D." <jan.h.d@swipnet.se> writes:
> > It turns out that since the container widget Emacs uses isn't double
> > buffered, all the children (scroll bars) does not get double buffering
> > either.
> > 
> > I have checked in a fix for this (actually a couple a days ago, but it was 
> > incomplete), hopefully it finally fixes this problem (hey, one can hope :-).
> 
> Yes, this seems to have fixed the flickering problem completely
> (there are still some rough updates when the emacs window configuration
> changes, but that's a relatively rare event, and I guess this sort of
> thing is probably never going to be perfect, given that GTK is somewhat
> bolted onto emacs).

There are some issues I know about, for example the tool bar does not behave
at startup.  There are more redraws of GTK widgets than what is optimal.

> BTW, I find that I can get better scrolling behavior with emacs/GTK if I
> set `redisplay-dont-pause' to t -- otherwise, if I e.g., hold down a
> scroll key (say C-v), scrolling updates the scroll bar smoothly, but the
> text window only gets updated when I stop scrolling.  Any comment on
> this?  [My processor seems to be fast enough to keep up when
> redisplay-dont-pause is t]

It must be that the redisplay code decided to delay the redisplay
because of other input (keys or X events).
I can hardly see any difference when I set redisplay-dont-pause to t
but I imagine redisplay-dont-pause fills the same job as "smooth-scroll"
in xterm.  In that case what you see is the intended behaviour, less
redisplay to use less CPU-time.

	Jan D.

Re: Emacs GTK scroll-bar flickering

[Richard Stallman]

    BTW, I find that I can get better scrolling behavior with emacs/GTK if I
    set `redisplay-dont-pause' to t -- otherwise, if I e.g., hold down a
    scroll key (say C-v), scrolling updates the scroll bar smoothly, but the
    text window only gets updated when I stop scrolling.  Any comment on
    this?  [My processor seems to be fast enough to keep up when
    redisplay-dont-pause is t]

Does redisplay do a better job of keeping up when Emacs doesn't use
GTK?  If so, it suggests that redisplay with GTK is much slower.
The thing to do is investigate what is taking the time.

Re: Emacs GTK scroll-bar flickering

[Richard Stallman]

    This again seems to be related to the fact that my GTK theme is very
    slow to draw -- if I switch to a more svelte theme, redisplay during
    scrolling is `normal' regardless of the setting of redisplay-dont-pause.

    I guess that even thought it seems fast enough, the theme uses enough
    CPU drawing itself that emacs gets confused and suppresses the text
    redisplay during scrolling.

What aspects of the GTK theme need to be redrawn just because
Emacs scrolls the buffer?  Perhaps too much is getting redrawn
at the GTK level; that could be a bug.

Re: Emacs GTK scroll-bar flickering

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> What aspects of the GTK theme need to be redrawn just because
> Emacs scrolls the buffer?  Perhaps too much is getting redrawn
> at the GTK level; that could be a bug.

I don't know, it seems to just be the scrollbar; again, the standard
themes seem OK (so I don't think this is a critical problem), there's
just something very slow about my theme.  Menus are very slow too, when
I use them.

One thing is that GTK seems to do full redraws of components by default,
and rely on graphical double-buffering to make it look smooth.  This
seems to be a fundamental aspect of GTK though, so I guess it's not easy
to fix.

-miles
-- 
The secret to creativity is knowing how to hide your sources.
  --Albert Einstein

Re: Emacs GTK scroll-bar flickering

[Richard Stallman]

    I don't know, it seems to just be the scrollbar; again, the standard
    themes seem OK (so I don't think this is a critical problem), there's
    just something very slow about my theme.  Menus are very slow too, when
    I use them.

If you run under GDB and arrange to stop it while it's doing this work,
after a few backtraces you could see what's taking the time.