This demonstrates that some Apple bug prevents the software from working normally, either in XQuartz, or at lower level. It was running like this before El Capitan when it became slow.
X2go macos xquartz full#
IT RUNS AT FULL SPEED!!! Same program, same computer, same versions of software. Second part of video shows how the program works, if you start the Mac computer, login as one user, and then start another session (without closing first one), and then start the X11 based program which uses XQuartz. Other operations work normally, but use interface is too slow fully productive use. I show only opening of menus by passing the mouse over menu title, but main slowness is actually in resizing windows. I have created a short video to demonstrate the how slow is XQuartz with the Motif based textile CAD software, and a hack to make it faster. # run demo WITH uncover hack (about 300 msec)ĭYLD_LIBRARY_PATH=/tmp/tcl8.5.18/unix:/tmp/tk8.5.18/unix /tmp/tk8.5.18/unix/wish zz.tcl 1 # run demo WITHOUT uncover hack (takes 7-8 secs)ĭYLD_LIBRARY_PATH=/tmp/tcl8.5.18/unix:/tmp/tk8.5.18/unix /tmp/tk8.5.18/unix/wish zz.tcl 0 # speedup req's Xwin (exist OK, too) to get behind If -e bash -norc &]Īfter 50 # req'd else xterm not drawn in time (> ~10ms) # X11/tk/wish demo huge slowdown 10.10+ drawing speed, hack workaround # put following demo tcl/tk script into: /tmp/zz.tcl The uncover hack gets us back to only 5x slower. It takes 7-8 seconds to do the same thing, over 100x
X2go macos xquartz mac os x#
On Mac OS X 10.12.5, running on same hardware, On Mac OS X 10.6.8, it takes 70 msec to draw 400 X11/tkīuttons. OS X 10.10+ caused by uncovering a drawing-in-progress The massive increase in X11 drawing speed (20x) on Mac Here is a completely non-invasive way to demonstrate I don't have access to other Mac systems, so I don't know exactly what combination of OS X version, XQuartz version, or hardware, seem to have this problem. I realize that this is not a direct comparison, but a factor of 20 difference in speed doesn't seem right. The same program run on Linux via a modest PC-based virtual machine with 24-bit color takes about 16 seconds.
On my Mac mini, the program takes around 42 sec on 8-bit color, and over five minutes on the default 24-bit color settings, which means the 24-bit case is more than 7x slower. To test things, I made a simple X11 program, attached here, which calls XDrawLine() many times. I think earlier versions of XQuartz might not have had this problem.
I also saw drastic slowdown in my own X11 applications, and recently discovered that it seems to be related to whether XQuartz is in TrueColor (24 bit) or PseudoColor (8 bit) mode. Xquartz 2.7.8 / Mac OS X 10.11.1 / Mac mini (Late 2014, Intel Iris Graphics)Īs long ago as Mac OS X Yosemite, some folks have reported graphics slowdowns, for example: It is also generally slow compared to X11 performance on Linux. X11 drawing seems to be 7x slower when XQuartz "Preferences/Output" is not set to "256 colors". Simple test of XDrawLine to probe drawing speed performance.
0 kommentar(er)
