9:12 a.m.
I've noticed that both 21.2.38 and 21.2.39 have a problem when there is a
slow link like an ISDN line between the X Server and a copy of XEmacs
running on Solaris. Some operations (such as copy-primary-selection or
kill-line) transmit a lot more data than they should, around 30K. Other
similar operations (such as advertized-undo) are very fast and transmit
almost no data. I usually work with the Windows version of XEmacs and
don't know much about X or the use of it by XEmacs so I don't know what's
going on. I can send someone a trace of the traffic, but it should be easy
to reproduce since it happens even with when XEmacs is run with -vanilla.
I don't know when this started happening since I haven't built a Unix
version for a while. I'm also behind in my EMail so this may have been
discussed although I didn't see it in a quick scan. If it's an old topic,
I apologize.
Mike Alexander <mailto:mta＠arbortext.com>
Arbortext, Inc. +1-734-997-0200
7:01 p.m.
I've noticed that both 21.2.38 and 21.2.39 have a problem when
there is a
slow link like an ISDN line between the X Server and a copy of XEmacs
running on Solaris. Some operations (such as copy-primary-selection or
kill-line) transmit a lot more data than they should, around 30K.
I second that. It takes at least 2 seconds to kill-line when I work
remotely
over ISDN. I've started running xemacs -nw in an xterm as a workaround
when I can't run Xemacs on the same machine as the Xserver.
Cheers!greg
10:08 a.m.
On Thu, 04 Jan 2001 04:12:53 -0500 Mike Alexander wrote:
I've noticed that both 21.2.38 and 21.2.39 have a problem when
there is a
slow link like an ISDN line between the X Server and a copy of XEmacs
running on Solaris. Some operations (such as copy-primary-selection or
kill-line) transmit a lot more data than they should, around 30K.
truss'ing the X library calls Xemacs makes shows that the time is
spent in the Motif clipboard code (XmClipboardStartCopy,
XmClipboardCopy, XmClipboardEndCopy).
That leads one to select-x.c:hack_motif_clipboard_selection where
there's a comment about this slow behaviour with Motif selections. An
old hack to avoid the problem is commented out because it introduces
correctness problems.
Even with Xemacs running on the same machine as the X server there's a
noticable sluggishness with kill-line. What's the best way to
avoid this? Stop using Motif altogether?
Cheers!greg
11:07 a.m.
At 02:08 05/01/01 -0800, Greg Onufer wrote:
Even with Xemacs running on the same machine as the X server
there's a
noticable sluggishness with kill-line. What's the best way to
avoid this? Stop using Motif altogether?
We should make the optimization an option
andy
--------------------------------------------------------------
Dr Andy Piper
Principal Consultant, BEA Systems Ltd
7:51 p.m.
Try this.
andy
2001-01-23 Andy Piper <andy.piper(a)beasys.org>
* select.c (Fown_selection_internal): pass owned_p
* select-msw.c (mswindows_own_selection): New Signature.
* console.h (struct console_methods): add owned_p to
_own_selection.
* select-x.c (x_own_selection): pass owned_p
(hack_motif_clipboard_selection): use owned_p
(vars_of_select_x): new variable -
x_selection_strict_motif_ownership.
At 04:12 04/01/01 -0500, Mike Alexander wrote:
I've noticed that both 21.2.38 and 21.2.39 have a problem when
there is a
slow link like an ISDN line between the X Server and a copy of XEmacs
running on Solaris. Some operations (such as copy-primary-selection or
kill-line) transmit a lot more data than they should, around 30K. Other
similar operations (such as advertized-undo) are very fast and transmit
almost no data. I usually work with the Windows version of XEmacs and
don't know much about X or the use of it by XEmacs so I don't know what's
going on. I can send someone a trace of the traffic, but it should be
easy to reproduce since it happens even with when XEmacs is run with
-vanilla. I don't know when this started happening since I haven't built a
Unix version for a while. I'm also behind in my EMail so this may have
been discussed although I didn't see it in a quick scan. If it's an old
topic, I apologize.
Mike Alexander <mailto:mta＠arbortext.com>
Arbortext, Inc. +1-734-997-0200
--------------------------------------------------------------
Dr Andy Piper
Principal Consultant, BEA Systems Ltd
2:25 a.m.
Unfortunately that wasn't quite enough. That patch is basically ok (but
see below), but when hack_motif_clipboard_selection is called owned_p is
always zero which makes the new x_selection_strict_motif_ownership switch
irrelevant. The problem is that own-selection-internal is always called
(as far as I can tell) with the how-to-add parameter defaulted to nil. In
this case it doesn't set prev_value and hence owned_p is nil when the
device method is called. The attached patch seem to fix this.
It also seems to me that the documentation for
x-selection-strict-motif-ownership is backwards. It says that if it is
true (the default) then XEmacs won't own the clipboard again if it already
owns it, but it seems to be just the opposite. Since it's not clear to me
which the default should be and whether the documentation or the code is
wrong, I didn't change anything.
Mike Alexander <mailto:mta＠arbortext.com>
Arbortext, Inc. +1-734-997-0200
--On Tuesday, January 23, 2001 7:51 PM +0000 Andy Piper <andy(a)xemacs.org>
wrote:
Try this.
andy
2001-01-23 Andy Piper <andy.piper(a)beasys.org>
* select.c (Fown_selection_internal): pass owned_p
* select-msw.c (mswindows_own_selection): New Signature.
* console.h (struct console_methods): add owned_p to
_own_selection.
* select-x.c (x_own_selection): pass owned_p
(hack_motif_clipboard_selection): use owned_p
(vars_of_select_x): new variable -
x_selection_strict_motif_ownership.
At 04:12 04/01/01 -0500, Mike Alexander wrote:
> I've noticed that both 21.2.38 and 21.2.39 have a problem when there is
> a slow link like an ISDN line between the X Server and a copy of XEmacs
> running on Solaris. Some operations (such as copy-primary-selection or
> kill-line) transmit a lot more data than they should, around 30K. Other
> similar operations (such as advertized-undo) are very fast and transmit
> almost no data. I usually work with the Windows version of XEmacs and
> don't know much about X or the use of it by XEmacs so I don't know
> what's going on. I can send someone a trace of the traffic, but it
> should be easy to reproduce since it happens even with when XEmacs is
> run with -vanilla. I don't know when this started happening since I
> haven't built a Unix version for a while. I'm also behind in my EMail
> so this may have been discussed although I didn't see it in a quick
> scan. If it's an old topic, I apologize.
>
> Mike Alexander <mailto:mta＠arbortext.com>
> Arbortext, Inc. +1-734-997-0200
3:55 p.m.
At 21:25 28/01/01 -0500, Mike Alexander wrote:
Unfortunately that wasn't quite enough. That patch is basically
ok (but
see below), but when hack_motif_clipboard_selection is called owned_p is
always zero which makes the new x_selection_strict_motif_ownership switch
irrelevant. The problem is that own-selection-internal is always called
(as far as I can tell) with the how-to-add parameter defaulted to nil. In
this case it doesn't set prev_value and hence owned_p is nil when the
device method is called. The attached patch seem to fix this.
Cool. Go ahead and apply if you can.
It also seems to me that the documentation for
x-selection-strict-motif-ownership is backwards. It says that if it is
true (the default) then XEmacs won't own the clipboard again if it already
owns it, but it seems to be just the opposite. Since it's not clear to me
which the default should be and whether the documentation or the code is
wrong, I didn't change anything.
Uncertain about this. Possibly the default should be off rather than on.
andy
--------------------------------------------------------------
Dr Andy Piper
Principal Consultant, BEA Systems Ltd
8698
days inactive
8723
days old
6 comments
3 participants
participants (3)
-
Andy Piper -
Greg Onufer -
Mike Alexander