hi jeremy
All of your tests are still using the launchd socket. I want to know if
the issue is due to xauth with the new launchd socket path in Yosemite,
so to test that, please use the *traditional* socket rather than the
launchd socket. Please set DISPLAY to ":0" or ":1" or ":2" depending
on what your server is using. You can check the running processes with
ps to see the arguments passed to Xquartz to figure out what it should
be set to for testing.
sorry for not understanding
the first time.
I just now did the test you
originally asked for in bash:
DISPLAY=:0 /full/path/wish zz.tcl
Same 10 sec draw time.
I've appended (probably mailer-mangled) outputs
of ps and taskinfo.
cheers,
marty
Here is ps that suggested using DISPLAY=:0
##########################################################################
% ps auxwww | grep X11
319 ?? S 0:01.68
/Applications/Utilities/XQuartz.app/Contents/MacOS/X11.bin
329 ?? S 0:00.02 /opt/X11/bin/xterm -sb -sl 10000 -geometry
80x12+10+600
330 ?? S 0:00.00 /opt/X11/lib/X11/xinit/launchd_startx
/opt/X11/bin/startx -- /opt/X11/bin/Xquartz
331 ?? S 0:00.01 /bin/sh /opt/X11/bin/startx -- /opt/X11/bin/Xquartz
396 ?? S 0:00.00 /opt/X11/bin/xinit /opt/X11/lib/X11/xinit/xinitrc --
/opt/X11/bin/Xquartz :0 -nolisten tcp -auth /Users/sereno/.serverauth.331
399 ?? S 0:00.00 /opt/X11/bin/Xquartz :0 -nolisten tcp -auth
/Users/sereno/.serverauth.331
485 ?? S 0:00.06 /opt/X11/bin/quartz-wm
Here are taskinfo outputs (with wish8.5 running)
##########################################################################
root# taskinfo wish8.5
process: "wish8.5" [672]
coalition ID: 188
suspend count: 0
virtual bytes: 2.39 GB; resident bytes: 5.74 MB
run time: 1 s
user/system time (current threads): 0.032529 s / 0.014386 s
user/system time (terminated threads): 0.000000 s / 0.000000 s
interrupt wakeups: 0 (0 / nan% from platform idle)
default sched policy: POLICY_TIMESHARE
dirty tracking: untracked
boosts: 0 (0 externalized)
requested policy (0x50200):
req apptype: TASK_APPTYPE_APP_DEFAULT
req role: TASK_UNSPECIFIED
req qos clamp: THREAD_QOS_UNSPECIFIED
req base/override latency qos: LATENCY_QOS_TIER_UNSPECIFIED /
LATENCY_QOS_TIER_UNSPECIFIED
req base/override thruput qos: THROUGHPUT_QOS_TIER_UNSPECIFIED /
THROUGHPUT_QOS_TIER_UNSPECIFIED
req darwin BG: NO
req internal/external iotier: THROTTLE_LEVEL_TIER0 (IMPORTANT) /
THROTTLE_LEVEL_TIER0 (IMPORTANT)
req darwin BG iotier: THROTTLE_LEVEL_TIER2 (UTILITY)
req managed: NO
req other:
suppression behaviors:
effective policy (0x40000200):
eff role: TASK_UNSPECIFIED
eff latency qos: LATENCY_QOS_TIER_UNSPECIFIED
eff thruput qos: THROUGHPUT_QOS_TIER_UNSPECIFIED
eff darwin BG: NO
eff iotier: THROTTLE_LEVEL_TIER0 (IMPORTANT)
eff managed: NO
eff other:
imp_donor: YES
imp_receiver: DE-NAP
adaptive daemon: NO (boosted: NO)
##########################################################################
root# taskinfo quartz-wm
process: "quartz-wm" [485]
coalition ID: 189
suspend count: 0
virtual bytes: 2.47 GB; resident bytes: 7.05 MB
run time: 3152 s
user/system time (current threads): 0.055803 s / 0.049353 s
user/system time (terminated threads): 0.001216 s / 0.001540 s
interrupt wakeups: 25 (14 / 56.00% from platform idle)
default sched policy: POLICY_TIMESHARE
dirty tracking: untracked
boosts: 0 (0 externalized)
requested policy (0x100000120200):
req apptype: TASK_APPTYPE_DAEMON_STANDARD
req role: TASK_UNSPECIFIED
req qos clamp: THREAD_QOS_UNSPECIFIED
req base/override latency qos: LATENCY_QOS_TIER_0 /
LATENCY_QOS_TIER_UNSPECIFIED
req base/override thruput qos: THROUGHPUT_QOS_TIER_0 /
THROUGHPUT_QOS_TIER_UNSPECIFIED
req darwin BG: NO
req internal/external iotier: THROTTLE_LEVEL_TIER0 (IMPORTANT) /
THROTTLE_LEVEL_TIER0 (IMPORTANT)
req darwin BG iotier: THROTTLE_LEVEL_TIER2 (UTILITY)
req managed: NO
req other:
suppression behaviors:
effective policy (0x51010201):
eff role: TASK_UNSPECIFIED
eff latency qos: LATENCY_QOS_TIER_0
eff thruput qos: THROUGHPUT_QOS_TIER_0
eff darwin BG: NO
eff iotier: THROTTLE_LEVEL_TIER1 (STANDARD)
eff managed: NO
eff other:
imp_donor: YES
imp_receiver: NO
adaptive daemon: NO (boosted: NO)
##########################################################################
root# taskinfo X11.bin
process: "X11.bin" [319]
coalition ID: 188
suspend count: 0
virtual bytes: 2.58 GB; resident bytes: 56.20 MB
run time: 3179 s
user/system time (current threads): 2.211459 s / 1.456876 s
user/system time (terminated threads): 0.128282 s / 0.207724 s
interrupt wakeups: 10413 (9042 / 86.83% from platform idle)
default sched policy: POLICY_TIMESHARE
dirty tracking: untracked
boosts: 0 (0 externalized)
requested policy (0x100001152200):
req apptype: TASK_APPTYPE_APP_DEFAULT
req role: TASK_FOREGROUND_APPLICATION
req qos clamp: THREAD_QOS_UNSPECIFIED
req base/override latency qos: LATENCY_QOS_TIER_0 /
LATENCY_QOS_TIER_UNSPECIFIED
req base/override thruput qos: THROUGHPUT_QOS_TIER_0 /
THROUGHPUT_QOS_TIER_UNSPECIFIED
req darwin BG: NO
req internal/external iotier: THROTTLE_LEVEL_TIER0 (IMPORTANT) /
THROTTLE_LEVEL_TIER0 (IMPORTANT)
req darwin BG iotier: THROTTLE_LEVEL_TIER2 (UTILITY)
req managed: NO
req other: boosted
suppression behaviors:
effective policy (0x81110200):
eff role: TASK_FOREGROUND_APPLICATION
eff latency qos: LATENCY_QOS_TIER_0
eff thruput qos: THROUGHPUT_QOS_TIER_0
eff darwin BG: NO
eff iotier: THROTTLE_LEVEL_TIER0 (IMPORTANT)
eff managed: NO
eff other:
imp_donor: CURRRENTLY
imp_receiver: DE-NAP
adaptive daemon: NO (boosted: NO)
On Mon, 1 Dec 2014, Jeremy Huddleston Sequoia wrote:
Hi Marty,
All of your tests are still using the launchd socket. I want to know if the issue is due to xauth with the
new launchd socket path in Yosemite, so to test that, please use the *traditional* socket rather than the
launchd socket. Please set DISPLAY to ":0" or ":1" or ":2" depending on what
your server is using. You can check the running processes with ps to see the arguments passed to Xquartz to
figure out what it should be set to for testing.
Thanks,
Jeremy
On Dec 1, 2014, at 10:28, Marty Sereno <[email protected]> wrote:
hi jeremy
thanks much for the response.
the DISPLAY var on my 10.10.1 machine (Mac Pro, 6-core, D700's) looked OK:
DISPLAY=/private/tmp/com.apple.launchd.clFuL77xZD/org.macosforge.xquartz:0
and here is the socket:
buc06:sereno[7] ls -al /tmp/com.apple.launchd.clFuL77xZD
total 0
drwx------ 3 sereno wheel 102 Dec 1 18:09 ./
drwxrwxrwt 9 root wheel 306 Dec 1 18:09 ../
srw-rw-rw- 1 sereno wheel 0 Dec 1 18:09 org.macosforge.xquartz:0
For comparison, on my non-slow 10.6.8 machine (2011
MacBook Pro 17"), the DISPLAY var looks like this:
DISPLAY=/tmp/launch-MhYGZd/org.macosforge.xquartz:0
All the following uniformly take 10 sec (I assume you
meant a ';' in between DISPLAY= and /path/...),
on the 10.10.1 Mac Pro machine:
DISPLAY=/private/tmp/com.apple.launchd.clFuL77xZD/org.macosforge.xquartz:0
/Users/sereno/Developer/csurfsrc/tcltktix/bin/Darwin-x86_64/wish8.5
[source <script_below>, or paste script into wish prompt]
or
DISPLAY=/private/tmp/com.apple.launchd.clFuL77xZD/org.macosforge.xquartz:0
/tmp/zz.tcl # zz.tcl is wish script below
or
env \
DISPLAY=/private/tmp/com.apple.launchd.clFuL77xZD/org.macosforge.xquartz:0 \
/Users/sereno/Developer/csurfsrc/tcltktix/bin/Darwin-x86_64/wish8.5
or
env \
DISPLAY=/private/tmp/com.apple.launchd.clFuL77xZD/org.macosforge.xquartz:0 \
/Users/sereno/Developer/csurfsrc/tcltktix/bin/Darwin-x86_64/wish8.5 \
zz.tcl # zz.tcl is wish script below
Back in XQuartz 2.7.4, on my 10.6.8 machine, I noticed that
occasionally, the normally zippy tk/tix widget drawing would
suddenly slow way down after XQuartz had been running a while
(often through several sleeps). Again this was a 100x to 1000x
slowdown).
It would only be fixed by a reboot (logout/login restart win server
not enough). After XQuartz 2.7.6 or 2.7.7 (not sure which), the slowdown
never happened again (on 10.6.8). I never figured out what was causing
it then either. There were no system updates in between broken
and fixed.
I won't email you again unless I actually figure
something out :-}
cheers,
marty
On Sun, 30 Nov 2014, Jeremy Huddleston Sequoia wrote:
I wonder if this is related to the xauth timeout because it doesn't know about
the new Yosemite launchd socket path. If you launch XQuartz and then do
'DISPLAY=:0 /path/to/program', does it experience the delay. Note that your
DISPLAY may not actually be :0, so if that doesn't work, check what DISPLAY the
running X server is.
--Jeremy
On Nov 29, 2014, at 22:06, Tom Lane <[email protected]> wrote:
Marty Sereno <[email protected]> writes:
In XQuartz 2.7.7, running on Mac OS X 10.6.8,
the following program (source'd in a wish8.5.12
compiled on 10.6.8) takes about 10 milliseconds to
finish/display:
# display 400 buttons
for {set j 0} {$j < 20} {incr j} {
frame .f$j
pack .f$j -side top
for {set i 0} {$i < 20} {incr i} {
button .f$j.b$i -text asdf
pack .f$j.b$i -side left
}
}
On XQuartz 2.7.7 runnng on Mac OS X 10.10.1,
the same program (whether X11 tcl/tk was
compiled on 10.6.8 or on 10.10.1) takes
about 10 sec to display (1000x slowdown).
Hm ... I see a similar delay if I run this as a script file,
but if I copy/paste it into an interactive wish, it seems to be
about a second or so. Which is still a lot, but the context
makes a difference.
Also, I use exmh (a tcl/tk email handler) constantly, and I've not
noticed any particular slowdown in it with Yosemite. So it's not
true that tk is broken completely. You'll probably need to do some
sleuthing ...
regards, tom lane
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/x11-users/jeremyhu%40freedesktop.org
This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/x11-users/archive%40mail-archive.com
This email sent to [email protected]
