Glitches with the GTK toolkit

Glitches with the GTK toolkit

[Jérôme Marant]

Hi,

I noticed an ugly display behaviour with Emacs compiled with the GTK toolkit:
 
When I make a text quickly scroll with a scroll bar, the text gets shrinked
until I stop moving the scroll bar.

I don't experience such a problem when Emacs is compiled with AW.

Cheers,

-- 
Jérôme Marant

Re: Glitches with the GTK toolkit

[Miles Bader]

jmarant@free.fr (Jérôme Marant) writes:
> I noticed an ugly display behaviour with Emacs compiled with the GTK toolkit:
> 
> When I make a text quickly scroll with a scroll bar, the text gets shrinked
> until I stop moving the scroll bar.

I don't understand what you mean by `the text gets shrinked'; quick
scrolling with the scrollbar under GTK looks fine to me.

-Miles
-- 
"1971 pickup truck; will trade for guns"

Re: Glitches with the GTK toolkit

[Kim F. Storm]

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

> Jérôme Marant <jmarant@free.fr> writes:
> > For instance, when I quickly move the scrollbar up, the bottom of the
> > buffer (the visible part) is not properly updated: only some bits of
> > the top of the buffer seem to scroll which give the impression of
> > shrinking.
> 
> It sounds like the redraw is getting interrupted while still not
> complete, which is normal behavior when a system's too slow to keep up.
> It should redraw completely as soon as it can.
> 
> What do you think it should do in this case?

Does (setq redisplay-dont-pause t) make a difference ?

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

Re: Glitches with the GTK toolkit

[Jérôme Marant]

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

> jmarant@free.fr (Jérôme Marant) writes:
> > I noticed an ugly display behaviour with Emacs compiled with the GTK
> toolkit:
> > 
> > When I make a text quickly scroll with a scroll bar, the text gets
> shrinked
> > until I stop moving the scroll bar.
> 
> I don't understand what you mean by `the text gets shrinked'; quick
> scrolling with the scrollbar under GTK looks fine to me.

For instance, when I quickly move the scrollbar up, the bottom of the
buffer (the visible part) is not properly updated: only some bits of
the top of the buffer seem to scroll which give the impression of
shrinking.

-- 
Jérôme Marant

Re: Glitches with the GTK toolkit

[Miles Bader]

Jérôme Marant <jmarant@free.fr> writes:
> For instance, when I quickly move the scrollbar up, the bottom of the
> buffer (the visible part) is not properly updated: only some bits of
> the top of the buffer seem to scroll which give the impression of
> shrinking.

It sounds like the redraw is getting interrupted while still not
complete, which is normal behavior when a system's too slow to keep up.
It should redraw completely as soon as it can.

What do you think it should do in this case?

-Miles
-- 
Would you like fries with that?

Re: Glitches with the GTK toolkit

[Jérôme Marant]

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

> Jérôme Marant <jmarant@free.fr> writes:
> > For instance, when I quickly move the scrollbar up, the bottom of the
> > buffer (the visible part) is not properly updated: only some bits of
> > the top of the buffer seem to scroll which give the impression of
> > shrinking.
> 
> It sounds like the redraw is getting interrupted while still not
> complete, which is normal behavior when a system's too slow to keep up.
> It should redraw completely as soon as it can.

No, the system isn't too slow since it works fine when compiled
with athena widgets. 
I think there's something wrong with the GTK version.

-- 
Jérôme Marant

Re: Glitches with the GTK toolkit

[Jérôme Marant]

Quoting "Kim F. Storm" <storm@cua.dk>:

> Does (setq redisplay-dont-pause t) make a difference ?

It looks like it solves the problem. Thanks.
But I don't understand with it would be necessary with the GTK
port and wouldn't be necessary with the Athena one.

-- 
Jérôme Marant

Re: Glitches with the GTK toolkit

[Jan D.]

>> It sounds like the redraw is getting interrupted while still not
>> complete, which is normal behavior when a system's too slow to keep 
>> up.
>> It should redraw completely as soon as it can.
>
> No, the system isn't too slow since it works fine when compiled
> with athena widgets.
> I think there's something wrong with the GTK version.

GTK is very slow in itself, and scrollbars very much slower than any 
other
toolkit.  If you are running Gnome or any fancy theme, you probably have
pixmap scrollbar thumbs.  This means that each scroll has to render a
complete image (png usually) for each movement.  The Athena widget
just does XDrawRectangle, which is faster by a couple of magnitudes.

	Jan D.

Re: Glitches with the GTK toolkit

[Jérôme Marant]

"Jan D." <jan.h.d@swipnet.se> writes:

> GTK is very slow in itself, and scrollbars very much slower than any
> other
> toolkit.  If you are running Gnome or any fancy theme, you probably have
> pixmap scrollbar thumbs.  This means that each scroll has to render a
> complete image (png usually) for each movement.  The Athena widget
> just does XDrawRectangle, which is faster by a couple of magnitudes.

I have zero knowledge about the GTK code within Emacs but this problem
is related to refreshing the buffer which is not a GTK widget, is it?

I also tried something which is even worse:
When I split the main window (C-x 2) and move the modeline of
the top buffer, everything is flickering: both scrollbars and buffers.
It is pretty ugly.

-- 
Jérôme Marant

Re: Glitches with the GTK toolkit

[Jan D.]

>
> I have zero knowledge about the GTK code within Emacs but this problem
> is related to refreshing the buffer which is not a GTK widget, is it?

No, but I guess you only have one CPU, so if scrollbar rendering takes
longer time, there is less time to update the buffer.

> I also tried something which is even worse:
> When I split the main window (C-x 2) and move the modeline of
> the top buffer, everything is flickering: both scrollbars and buffers.
> It is pretty ugly.

Turn off scrollbars and see if there is a difference.

	Jan D.

Re: Glitches with the GTK toolkit

[Jérôme Marant]

"Jan D." <jan.h.d@swipnet.se> writes:

>>
>> I have zero knowledge about the GTK code within Emacs but this problem
>> is related to refreshing the buffer which is not a GTK widget, is it?
>
> No, but I guess you only have one CPU, so if scrollbar rendering takes
> longer time, there is less time to update the buffer.

OK, I see. But I guess Emacs' interaction with GTK widget is different from
standard GTK applications.

>> I also tried something which is even worse:
>> When I split the main window (C-x 2) and move the modeline of
>> the top buffer, everything is flickering: both scrollbars and buffers.
>> It is pretty ugly.
>
> Turn off scrollbars and see if there is a difference.

Yes, there is. It is OK without them :(

-- 
Jérôme Marant

http://marant.org

Re: Glitches with the GTK toolkit

[Jan D.]

>>> I have zero knowledge about the GTK code within Emacs but this 
>>> problem
>>> is related to refreshing the buffer which is not a GTK widget, is it?
>>
>> No, but I guess you only have one CPU, so if scrollbar rendering takes
>> longer time, there is less time to update the buffer.
>
> OK, I see. But I guess Emacs' interaction with GTK widget is different 
> from
> standard GTK applications.

Very much so.  Some of it is due to the way Emacs is made, and some is
due to the way GTK is made.  It is not a good fit...

	Jan D.

Re: Glitches with the GTK toolkit

[Miles Bader]

jmarant@nerim.net (Jérôme Marant) writes:
> I also tried something which is even worse:
> When I split the main window (C-x 2) and move the modeline of
> the top buffer, everything is flickering: both scrollbars and buffers.
> It is pretty ugly.

Yeah, I don't use GTK scrollbars with emacs at all, they just have too
many problems (the GTK menus & toolbar are pretty nice though).

-Miles
-- 
In New York, most people don't have cars, so if you want to kill a person, you
have to take the subway to their house.  And sometimes on the way, the train
is delayed and you get impatient, so you have to kill someone on the subway.
  [George Carlin]

Re: Glitches with the GTK toolkit

[Jérôme Marant]

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

> jmarant@nerim.net (Jérôme Marant) writes:
> > I also tried something which is even worse:
> > When I split the main window (C-x 2) and move the modeline of
> > the top buffer, everything is flickering: both scrollbars and buffers.
> > It is pretty ugly.
> 
> Yeah, I don't use GTK scrollbars with emacs at all, they just have too
> many problems (the GTK menus & toolbar are pretty nice though).

I usually don't use menus and toolbar, but I use the scrollbar.
These are pretty bad news for me. If the GTK can't technicaly be
improved, I'll have to get back to Athena widget.

BTW, I decided to try the GDB UI, so I reanabled the toolbar.
Why, with Athena widgets is the toolbar so ugly? (even since
21.1). There is some kind of empty space at the bottom of
icons and I didn't find a way to remove it.

-- 
Jérôme Marant

Re: Glitches with the GTK toolkit

[Jérôme Marant]

Quoting "Jan D." <jan.h.d@swipnet.se>:

> > OK, I see. But I guess Emacs' interaction with GTK widget is different 
> > from
> > standard GTK applications.
> 
> Very much so.  Some of it is due to the way Emacs is made, and some is
> due to the way GTK is made.  It is not a good fit...

I'm disappointed. I'll have to get back to the Athena version since
I often use scrollbars.
Are there really no workarounds? Thanks.

-- 
Jérôme Marant

Re: Glitches with the GTK toolkit

[Jan D.]

> Quoting "Jan D." <jan.h.d@swipnet.se>:
>
>>> OK, I see. But I guess Emacs' interaction with GTK widget is 
>>> different
>>> from
>>> standard GTK applications.
>>
>> Very much so.  Some of it is due to the way Emacs is made, and some is
>> due to the way GTK is made.  It is not a good fit...
>
> I'm disappointed. I'll have to get back to the Athena version since
> I often use scrollbars.
> Are there really no workarounds? Thanks.

Well, apart from getting a faster machine, you can try a different GTK 
theme,
not all are pixmap based.  Configure Emacs --without-toolkit-scroll-bars
is one thing to do, but if you don't use menus or toolbars, this becomes
almost the same as compiling for pure X.

	Jan D.

Re: Glitches with the GTK toolkit

[Kim F. Storm]

Jérôme Marant <jmarant@free.fr> writes:

> BTW, I decided to try the GDB UI, so I reanabled the toolbar.
> Why, with Athena widgets is the toolbar so ugly? (even since
> 21.1). There is some kind of empty space at the bottom of
> icons and I didn't find a way to remove it.

It is an unfortunate effect of the display engine being line based
rather than pixel based -- meaning that the height of all windows
(including the toolbar window) in a frame must be a multiple of the
the default line height.  So the toolbar is padded to make it fulfill
this requirement.  I have it on my to-do list to fix this, but it will
not happen anytime soon.

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

Re: Glitches with the GTK toolkit

[Jérôme Marant]

"Jan D." <jan.h.d@swipnet.se> writes:

>> I'm disappointed. I'll have to get back to the Athena version since
>> I often use scrollbars.
>> Are there really no workarounds? Thanks.
>
> Well, apart from getting a faster machine, you can try a different GTK

I'm currently running a ppc G3 800Mhz, which is equivalent to a 1Ghz
Pentium, so it should be enough for text scrolling :-)

> theme,
> not all are pixmap based.  Configure Emacs --without-toolkit-scroll-bars

I remove every .gtkrc* around and it is slightly better, you are right.

> is one thing to do, but if you don't use menus or toolbars, this becomes
> almost the same as compiling for pure X.

Thanks.

-- 
Jérôme Marant

Re: Glitches with the GTK toolkit

[Jérôme Marant]

storm@cua.dk (Kim F. Storm) writes:

> Jérôme Marant <jmarant@free.fr> writes:
>
>> BTW, I decided to try the GDB UI, so I reanabled the toolbar.
>> Why, with Athena widgets is the toolbar so ugly? (even since
>> 21.1). There is some kind of empty space at the bottom of
>> icons and I didn't find a way to remove it.
>
> It is an unfortunate effect of the display engine being line based
> rather than pixel based -- meaning that the height of all windows
> (including the toolbar window) in a frame must be a multiple of the
> the default line height.  So the toolbar is padded to make it fulfill
> this requirement.  I have it on my to-do list to fix this, but it will
> not happen anytime soon.

Gosh, I've never suspected that the toolbar was implemented as a frame.
Why so? It sounds a strange idea to me.

-- 
Jérôme Marant

Re: Glitches with the GTK toolkit

[Miles Bader]

On Wed, May 12, 2004 at 11:07:48PM +0200, J?r?me Marant wrote:
> Gosh, I've never suspected that the toolbar was implemented as a frame.
> Why so? It sounds a strange idea to me.

It's not, but the (non-GTK) toolbar is implemented using the emacs display
engine which has aforementioned restriction in many places.  IIRC, it's more
like a funny sort of window than a frame (not exactly that either though --
e.g., I don't think it shows up in the window tree).

-Miles
-- 
Run away!  Run away!

Re: Glitches with the GTK toolkit

[Eli Zaretskii]

> From: jmarant@nerim.net (=?iso-8859-15?q?J=E9r=F4me_Marant?=)
> Date: Wed, 12 May 2004 23:07:48 +0200
> 
> Gosh, I've never suspected that the toolbar was implemented as a frame.

It's not a frame, it's a line (which is a part of a frame) that is
treated specially.

Re: Glitches with the GTK toolkit

[Jérôme Marant]

Quoting Miles Bader <miles@gnu.org>:

> On Wed, May 12, 2004 at 11:07:48PM +0200, J?r?me Marant wrote:
> > Gosh, I've never suspected that the toolbar was implemented as a frame.
> > Why so? It sounds a strange idea to me.
> 
> It's not, but the (non-GTK) toolbar is implemented using the emacs display
> engine which has aforementioned restriction in many places.  IIRC, it's more
> like a funny sort of window than a frame (not exactly that either though --
> e.g., I don't think it shows up in the window tree).

I still think using the Emacs display engine for that purpose is
strange. Why not implementing a toolbar the XEmacs way?

-- 
Jérôme Marant

Re: Glitches with the GTK toolkit

[Jérôme Marant]

Quoting Eli Zaretskii <eliz@gnu.org>:

> > From: jmarant@nerim.net (=?iso-8859-15?q?J=E9r=F4me_Marant?=)
> > Date: Wed, 12 May 2004 23:07:48 +0200
> > 
> > Gosh, I've never suspected that the toolbar was implemented as a frame.
> 
> It's not a frame, it's a line (which is a part of a frame) that is
> treated specially.

But it is a frame dedicated at the toolbar anyway. It is the implemention
of the toolbar via the display engine that looks unusual to me.

Regards,

-- 
Jérôme Marant

Re: Glitches with the GTK toolkit

[Kim F. Storm]

Jérôme Marant <jmarant@free.fr> writes:

> Quoting Eli Zaretskii <eliz@gnu.org>:
> 
> > > From: jmarant@nerim.net (=?iso-8859-15?q?J=E9r=F4me_Marant?=)
> > > Date: Wed, 12 May 2004 23:07:48 +0200
> > > 
> > > Gosh, I've never suspected that the toolbar was implemented as a frame.
> > 
> > It's not a frame, it's a line (which is a part of a frame) that is
> > treated specially.
> 
> But it is a frame dedicated at the toolbar anyway. It is the implemention
> of the toolbar via the display engine that looks unusual to me.

In some toolkits it is a separate frame (in which case it does not need
padding).

Otherwise, it is a special kind of emacs window (inside a frame), which
is handled by redisplay.

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

Re: Glitches with the GTK toolkit

[Miles Bader]

On Thu, May 13, 2004 at 01:55:12PM +0200, J?r?me Marant wrote:
> > It's not, but the (non-GTK) toolbar is implemented using the emacs
> > display engine which has aforementioned restriction in many places.
> > IIRC, it's more like a funny sort of window than a frame (not exactly
> > that either though -- e.g., I don't think it shows up in the window
> > tree).
> 
> I still think using the Emacs display engine for that purpose is
> strange. Why not implementing a toolbar the XEmacs way?

I don't know, you'll have to ask Gerd.  I expect it was easier this way.

[After all, you don't need just display capability, but also input handling,
etc, and things like overflows have to interact gracefully with the rest of
the display engine -- I don't know if GTK even handles the latter well.]

-Miles
-- 
Would you like fries with that?

Re: Glitches with the GTK toolkit

[Jérôme Marant]

Quoting "Kim F. Storm" <storm@cua.dk>:

 of the toolbar via the display engine that looks unusual to me.
> 
> In some toolkits it is a separate frame (in which case it does not need
> padding).
> 
> Otherwise, it is a special kind of emacs window (inside a frame), which
> is handled by redisplay.

OK.

-- 
Jérôme Marant

Re: Glitches with the GTK toolkit

[YAMAMOTO Mitsuharu]

[-- Attachment #1: Type: text/plain, Size: 1091 bytes --]

This topic is somewhat old.  But I'd like to take up this because the
similar problem also occurs in Carbon Emacs, where drawing text is
much slower than in X11.

>>>>> On Tue, 11 May 2004 23:34:53 +0200, jmarant@nerim.net (Jérôme Marant) said:

>>> I also tried something which is even worse: When I split the main
>>> window (C-x 2) and move the modeline of the top buffer, everything
>>> is flickering: both scrollbars and buffers.  It is pretty ugly.
>> 
>> Turn off scrollbars and see if there is a difference.

> Yes, there is. It is OK without them :(

How about preventing redisplay from pausing in the case that there are
no pending inputs other than the mouse movement?  One can "squeeze" a
sequence of mouse movement events into the latest one, and I think
it's OK to postpone such kind of events until redisplay is completed.

Here's a patch for testing the above idea.  It would be better to make
redisplay pause even in the case mentioned above, if the latest mouse
movement gets too old.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

[-- Attachment #2: diff.gz --]
[-- Type: application/octet-stream, Size: 2662 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Glitches with the GTK toolkit

[Jan D.]

YAMAMOTO Mitsuharu wrote:

>This topic is somewhat old.  But I'd like to take up this because the
>similar problem also occurs in Carbon Emacs, where drawing text is
>much slower than in X11.
>

In the GTK case, it was the drawing of scroll bars that was slow.  But 
it is a lot faster now, it should be equally fast as for other GTK 
applications.

>How about preventing redisplay from pausing in the case that there are
>no pending inputs other than the mouse movement?  One can "squeeze" a
>sequence of mouse movement events into the latest one, and I think
>it's OK to postpone such kind of events until redisplay is completed.
>
>Here's a patch for testing the above idea.  It would be better to make
>redisplay pause even in the case mentioned above, if the latest mouse
>movement gets too old.
>

On GTK I actually don't see any difference, but on OSX I do.  It is an 
improvement, and slower machines will probably benefit.  Does this 
affect any other operations that dragging the mode line?

    Jan D.

Re: Glitches with the GTK toolkit

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 07 Jan 2005 18:32:54 +0100, "Jan D." <jan.h.d@swipnet.se> said:

> On GTK I actually don't see any difference, but on OSX I do.  It is an 
> improvement, and slower machines will probably benefit.  Does this
> affect any other operations that dragging the mode line?

Yes.  Dragging the scroll bar thumb, which is currently implemented
using `track-mouse' on OSX, would behave as if redisplay-dont-pause
were set to `t'.  Dragging the thumb updates only a few lines on slow
machines without the patch.  I think pausing during redisplay is good
for other kinds of events, but not for mouse movements because they
usually come with a short interval.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Glitches with the GTK toolkit

[Jan D.]

>>>>>> On Fri, 07 Jan 2005 18:32:54 +0100, "Jan D." <jan.h.d@swipnet.se> 
>>>>>> said:
>
>> On GTK I actually don't see any difference, but on OSX I do.  It is an
>> improvement, and slower machines will probably benefit.  Does this
>> affect any other operations that dragging the mode line?
>
> Yes.  Dragging the scroll bar thumb, which is currently implemented
> using `track-mouse' on OSX, would behave as if redisplay-dont-pause
> were set to `t'.  Dragging the thumb updates only a few lines on slow
> machines without the patch.  I think pausing during redisplay is good
> for other kinds of events, but not for mouse movements because they
> usually come with a short interval.

The scroll bar dragging becomes smoother on OSX.  I think this patch 
should be checked in.  As you say, mouse movements comes in bursts so 
pausing doesn't need to be done.

	Jan D.