unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Glitches with the GTK toolkit
@ 2004-05-10 13:51 Jérôme Marant
  2004-05-11  1:24 ` Miles Bader
  0 siblings, 1 reply; 30+ messages in thread
From: Jérôme Marant @ 2004-05-10 13:51 UTC (permalink / raw)



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

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Glitches with the GTK toolkit
  2004-05-10 13:51 Glitches with the GTK toolkit Jérôme Marant
@ 2004-05-11  1:24 ` Miles Bader
  2004-05-11  8:03   ` Jérôme Marant
  0 siblings, 1 reply; 30+ messages in thread
From: Miles Bader @ 2004-05-11  1:24 UTC (permalink / raw)
  Cc: emacs-devel

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"

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Glitches with the GTK toolkit
  2004-05-11  8:45     ` Miles Bader
@ 2004-05-11  6:56       ` Kim F. Storm
  2004-05-11 18:33         ` Jérôme Marant
  2004-05-11 18:30       ` Jérôme Marant
  1 sibling, 1 reply; 30+ messages in thread
From: Kim F. Storm @ 2004-05-11  6:56 UTC (permalink / raw)
  Cc: Jérôme Marant, emacs-devel

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

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Glitches with the GTK toolkit
  2004-05-11  1:24 ` Miles Bader
@ 2004-05-11  8:03   ` Jérôme Marant
  2004-05-11  8:45     ` Miles Bader
  0 siblings, 1 reply; 30+ messages in thread
From: Jérôme Marant @ 2004-05-11  8:03 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Glitches with the GTK toolkit
  2004-05-11  8:03   ` Jérôme Marant
@ 2004-05-11  8:45     ` Miles Bader
  2004-05-11  6:56       ` Kim F. Storm
  2004-05-11 18:30       ` Jérôme Marant
  0 siblings, 2 replies; 30+ messages in thread
From: Miles Bader @ 2004-05-11  8:45 UTC (permalink / raw)
  Cc: emacs-devel

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?

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Glitches with the GTK toolkit
  2004-05-11  8:45     ` Miles Bader
  2004-05-11  6:56       ` Kim F. Storm
@ 2004-05-11 18:30       ` Jérôme Marant
  2004-05-11 19:17         ` Jan D.
  1 sibling, 1 reply; 30+ messages in thread
From: Jérôme Marant @ 2004-05-11 18:30 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Glitches with the GTK toolkit
  2004-05-11  6:56       ` Kim F. Storm
@ 2004-05-11 18:33         ` Jérôme Marant
  0 siblings, 0 replies; 30+ messages in thread
From: Jérôme Marant @ 2004-05-11 18:33 UTC (permalink / raw)
  Cc: emacs-devel, Miles Bader

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

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Glitches with the GTK toolkit
  2004-05-11 18:30       ` Jérôme Marant
@ 2004-05-11 19:17         ` Jan D.
  2004-05-11 20:44           ` Jérôme Marant
  0 siblings, 1 reply; 30+ messages in thread
From: Jan D. @ 2004-05-11 19:17 UTC (permalink / raw)
  Cc: emacs-devel, Miles Bader

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

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Glitches with the GTK toolkit
  2004-05-11 19:17         ` Jan D.
@ 2004-05-11 20:44           ` Jérôme Marant
  2004-05-11 21:18             ` Jan D.
  2004-05-12  1:33             ` Miles Bader
  0 siblings, 2 replies; 30+ messages in thread
From: Jérôme Marant @ 2004-05-11 20:44 UTC (permalink / raw)
  Cc: emacs-devel

"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

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Glitches with the GTK toolkit
  2004-05-11 20:44           ` Jérôme Marant
@ 2004-05-11 21:18             ` Jan D.
  2004-05-11 21:34               ` Jérôme Marant
  2004-05-12  1:33             ` Miles Bader
  1 sibling, 1 reply; 30+ messages in thread
From: Jan D. @ 2004-05-11 21:18 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Glitches with the GTK toolkit
  2004-05-11 21:18             ` Jan D.
@ 2004-05-11 21:34               ` Jérôme Marant
  2004-05-11 21:53                 ` Jan D.
  2005-01-05 11:40                 ` YAMAMOTO Mitsuharu
  0 siblings, 2 replies; 30+ messages in thread
From: Jérôme Marant @ 2004-05-11 21:34 UTC (permalink / raw)
  Cc: emacs-devel

"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

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Glitches with the GTK toolkit
  2004-05-11 21:34               ` Jérôme Marant
@ 2004-05-11 21:53                 ` Jan D.
  2004-05-12 11:37                   ` Jérôme Marant
  2005-01-05 11:40                 ` YAMAMOTO Mitsuharu
  1 sibling, 1 reply; 30+ messages in thread
From: Jan D. @ 2004-05-11 21:53 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Glitches with the GTK toolkit
  2004-05-11 20:44           ` Jérôme Marant
  2004-05-11 21:18             ` Jan D.
@ 2004-05-12  1:33             ` Miles Bader
  2004-05-12 11:34               ` Jérôme Marant
  1 sibling, 1 reply; 30+ messages in thread
From: Miles Bader @ 2004-05-12  1:33 UTC (permalink / raw)
  Cc: Jan D., emacs-devel

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]

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Glitches with the GTK toolkit
  2004-05-12  1:33             ` Miles Bader
@ 2004-05-12 11:34               ` Jérôme Marant
  2004-05-12 18:33                 ` Kim F. Storm
  0 siblings, 1 reply; 30+ messages in thread
From: Jérôme Marant @ 2004-05-12 11:34 UTC (permalink / raw)
  Cc: Jan D., emacs-devel

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

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Glitches with the GTK toolkit
  2004-05-11 21:53                 ` Jan D.
@ 2004-05-12 11:37                   ` Jérôme Marant
  2004-05-12 11:58                     ` Jan D.
  0 siblings, 1 reply; 30+ messages in thread
From: Jérôme Marant @ 2004-05-12 11:37 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Glitches with the GTK toolkit
  2004-05-12 11:37                   ` Jérôme Marant
@ 2004-05-12 11:58                     ` Jan D.
  2004-05-12 21:03                       ` Jérôme Marant
  0 siblings, 1 reply; 30+ messages in thread
From: Jan D. @ 2004-05-12 11:58 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Glitches with the GTK toolkit
  2004-05-12 11:34               ` Jérôme Marant
@ 2004-05-12 18:33                 ` Kim F. Storm
  2004-05-12 21:07                   ` Jérôme Marant
  0 siblings, 1 reply; 30+ messages in thread
From: Kim F. Storm @ 2004-05-12 18:33 UTC (permalink / raw)
  Cc: Jan D., emacs-devel, Miles Bader

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

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Glitches with the GTK toolkit
  2004-05-12 11:58                     ` Jan D.
@ 2004-05-12 21:03                       ` Jérôme Marant
  0 siblings, 0 replies; 30+ messages in thread
From: Jérôme Marant @ 2004-05-12 21:03 UTC (permalink / raw)


"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

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Glitches with the GTK toolkit
  2004-05-12 18:33                 ` Kim F. Storm
@ 2004-05-12 21:07                   ` Jérôme Marant
  2004-05-12 22:32                     ` Miles Bader
  2004-05-13  5:46                     ` Eli Zaretskii
  0 siblings, 2 replies; 30+ messages in thread
From: Jérôme Marant @ 2004-05-12 21:07 UTC (permalink / raw)
  Cc: Jan D., emacs-devel, Miles Bader

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

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Glitches with the GTK toolkit
  2004-05-12 21:07                   ` Jérôme Marant
@ 2004-05-12 22:32                     ` Miles Bader
  2004-05-13 11:55                       ` Jérôme Marant
  2004-05-13  5:46                     ` Eli Zaretskii
  1 sibling, 1 reply; 30+ messages in thread
From: Miles Bader @ 2004-05-12 22:32 UTC (permalink / raw)
  Cc: Miles Bader, emacs-devel, Jan D., Kim F. Storm

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!

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Glitches with the GTK toolkit
  2004-05-12 21:07                   ` Jérôme Marant
  2004-05-12 22:32                     ` Miles Bader
@ 2004-05-13  5:46                     ` Eli Zaretskii
  2004-05-13 11:57                       ` Jérôme Marant
  1 sibling, 1 reply; 30+ messages in thread
From: Eli Zaretskii @ 2004-05-13  5:46 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Glitches with the GTK toolkit
  2004-05-12 22:32                     ` Miles Bader
@ 2004-05-13 11:55                       ` Jérôme Marant
  2004-05-13 19:30                         ` Miles Bader
  0 siblings, 1 reply; 30+ messages in thread
From: Jérôme Marant @ 2004-05-13 11:55 UTC (permalink / raw)
  Cc: Jan D., Kim F. Storm, emacs-devel

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

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Glitches with the GTK toolkit
  2004-05-13  5:46                     ` Eli Zaretskii
@ 2004-05-13 11:57                       ` Jérôme Marant
  2004-05-13 13:51                         ` Kim F. Storm
  0 siblings, 1 reply; 30+ messages in thread
From: Jérôme Marant @ 2004-05-13 11:57 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Glitches with the GTK toolkit
  2004-05-13 11:57                       ` Jérôme Marant
@ 2004-05-13 13:51                         ` Kim F. Storm
  2004-05-14  7:21                           ` Jérôme Marant
  0 siblings, 1 reply; 30+ messages in thread
From: Kim F. Storm @ 2004-05-13 13:51 UTC (permalink / raw)
  Cc: Eli Zaretskii, emacs-devel

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

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Glitches with the GTK toolkit
  2004-05-13 11:55                       ` Jérôme Marant
@ 2004-05-13 19:30                         ` Miles Bader
  0 siblings, 0 replies; 30+ messages in thread
From: Miles Bader @ 2004-05-13 19:30 UTC (permalink / raw)
  Cc: emacs-devel, Kim F. Storm, Jan D., 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?

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Glitches with the GTK toolkit
  2004-05-13 13:51                         ` Kim F. Storm
@ 2004-05-14  7:21                           ` Jérôme Marant
  0 siblings, 0 replies; 30+ messages in thread
From: Jérôme Marant @ 2004-05-14  7:21 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Glitches with the GTK toolkit
  2004-05-11 21:34               ` Jérôme Marant
  2004-05-11 21:53                 ` Jan D.
@ 2005-01-05 11:40                 ` YAMAMOTO Mitsuharu
  2005-01-07 17:32                   ` Jan D.
  1 sibling, 1 reply; 30+ messages in thread
From: YAMAMOTO Mitsuharu @ 2005-01-05 11:40 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Glitches with the GTK toolkit
  2005-01-05 11:40                 ` YAMAMOTO Mitsuharu
@ 2005-01-07 17:32                   ` Jan D.
  2005-01-08  9:11                     ` YAMAMOTO Mitsuharu
  0 siblings, 1 reply; 30+ messages in thread
From: Jan D. @ 2005-01-07 17:32 UTC (permalink / raw)
  Cc: emacs-devel

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.

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Glitches with the GTK toolkit
  2005-01-07 17:32                   ` Jan D.
@ 2005-01-08  9:11                     ` YAMAMOTO Mitsuharu
  2005-01-08  9:49                       ` Jan D.
  0 siblings, 1 reply; 30+ messages in thread
From: YAMAMOTO Mitsuharu @ 2005-01-08  9:11 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Glitches with the GTK toolkit
  2005-01-08  9:11                     ` YAMAMOTO Mitsuharu
@ 2005-01-08  9:49                       ` Jan D.
  0 siblings, 0 replies; 30+ messages in thread
From: Jan D. @ 2005-01-08  9:49 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 30+ messages in thread

end of thread, other threads:[~2005-01-08  9:49 UTC | newest]

Thread overview: 30+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-05-10 13:51 Glitches with the GTK toolkit Jérôme Marant
2004-05-11  1:24 ` Miles Bader
2004-05-11  8:03   ` Jérôme Marant
2004-05-11  8:45     ` Miles Bader
2004-05-11  6:56       ` Kim F. Storm
2004-05-11 18:33         ` Jérôme Marant
2004-05-11 18:30       ` Jérôme Marant
2004-05-11 19:17         ` Jan D.
2004-05-11 20:44           ` Jérôme Marant
2004-05-11 21:18             ` Jan D.
2004-05-11 21:34               ` Jérôme Marant
2004-05-11 21:53                 ` Jan D.
2004-05-12 11:37                   ` Jérôme Marant
2004-05-12 11:58                     ` Jan D.
2004-05-12 21:03                       ` Jérôme Marant
2005-01-05 11:40                 ` YAMAMOTO Mitsuharu
2005-01-07 17:32                   ` Jan D.
2005-01-08  9:11                     ` YAMAMOTO Mitsuharu
2005-01-08  9:49                       ` Jan D.
2004-05-12  1:33             ` Miles Bader
2004-05-12 11:34               ` Jérôme Marant
2004-05-12 18:33                 ` Kim F. Storm
2004-05-12 21:07                   ` Jérôme Marant
2004-05-12 22:32                     ` Miles Bader
2004-05-13 11:55                       ` Jérôme Marant
2004-05-13 19:30                         ` Miles Bader
2004-05-13  5:46                     ` Eli Zaretskii
2004-05-13 11:57                       ` Jérôme Marant
2004-05-13 13:51                         ` Kim F. Storm
2004-05-14  7:21                           ` Jérôme Marant

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).