XQuartz X11 drawing speed is 14x slower
Submitted by Frank Delaglio
Assigned to Jeremy Huddleston Sequoia
Description
Created attachment 120573 simple test of XDrawLine to probe drawing speed performance.
Greetings ..
Problem:
X11 drawing seems to be 7x slower when XQuartz "Preferences/Output" is not set to "256 colors". It is also generally slow compared to X11 performance on Linux.
Tested system:
Xquartz 2.7.8 / Mac OS X 10.11.1 / Mac mini (Late 2014, Intel Iris Graphics)
Details:
As long ago as Mac OS X Yosemite, some folks have reported graphics slowdowns, for example:
https://xquartz.macosforge.org/trac/ticket/2074
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. I think earlier versions of XQuartz might not have had this problem.
To test things, I made a simple X11 program, attached here, which calls XDrawLine() many times. 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.
The same program run on Linux via a modest PC-based virtual machine with 24-bit color takes about 16 seconds ... I realize that this is not a direct comparison, but a factor of 20 difference in speed doesn't seem right.
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.
Attachment 120573, "simple test of XDrawLine to probe drawing speed performance.":
xtest.c
Version: git
Activity
A user demonstrated that Native X11 XQuartz drawing is roughly 14 times slower than the same graphics rendered by a Linux virtual machine running on the exact same Mac:
https://www.ibbr.umd.edu/nmrpipe_files/xquartz_vs_virtual_linux.mov
In our case, this slowdown is bad enough to make the Mac version of our software unusable.
I'm also see slow graphics in Xquartz 2.7.9 (at millions of colours). I'm using the nmrDraw program, which is developed by Frank. I don't know if this is useful or not, but I have found the slowdown only occurs in the foreground X11 window.
For example, if I have two instances of nmrDraw open, both maximized to fill my screen:
-
if I force a redraw in the foreground instance, the process takes 10 seconds.
-
if I force a redraw in the foreground instance, "Cycle Windows" (Command-`) to put the redrawing window in the background, wait half a second, and cycle windows again to bring the redrawing window again to the foreground, the redraw is complete (i.e. the whole process takes 1 second instead of 10).
If I switch to 256 colours, the redraw takes 1 second no matter how I do it.
-
The same problem appeared in XBoard as installed from MacPorts a couple of months ago. As of that time XBoard is completely unusable on MacOSX for that reason, as a chess moves now take more than 1 second to draw.
For some discussion: http://talkchess.com/forum/viewtopic.php?t=59495
Movie: https://marcelk.net/2016-03-13/xslug.mov
The forum discussion mentions some optimisations that cold be done on the application side, but those are tangential to the underlying problem.
The forum discussion also mentions some actions that alleviated the issue. However, all of those were short-lived and the Xboard/Xquartz combination is now unconditionally slow.
Changing the display to 256 colors doesn't solve the problem because in that mode the pieces are not even drawn (the board becomes a large grey area).
Other developers show that this X11 slowdown is still a critical problem, and has been for about two years.
What has to be done to get this fixed, and why doesn't Apple seem to care?
http://core.tcl.tk/tk/tktview/01ef6cad3379f3586cd9f596222d5eeda2505f7c
What needs to be done:
Finish the implementation of XQuartz.app's replacement (eg: XtoQ in libxcwm).Why doesn't Apple seem to care?
This isn't an Apple product. Apple (through me) has explained what the solution is, but so far nobody has been interested in implementing it. As such, this will likely never be fixed.Jeremy, two quick questions.
You said "Apple (through me) has explained what the solution is". Could you give us any additional hints about what it is?
Second, does this imply that this problem is surely impossible to fix in XQuartz (or tk)?
For now, in absolute desperation to make my tk/X11/OpenGL cortical surface programs usable on Mac OS X 10.10+, I pop up an xterm (using tcl/tk: exec xterm &), in front of an in-progress X11/tk/wish window, and then immediately kill the xterm (via tcl/tk: exec kill $pid). The uncovered in-progress tk/X11 window then draws itself almost instantly (vs. an excruciating 15-20 seconds). The drawing speedup is proportional to the area of the tk/X11 window covered my the xterm.
Jeremy, two quick questions.
You said "Apple (through me) has explained what the solution is". Could you give us any additional hints about what it is?
Second, does this imply that this problem is surely impossible to fix in XQuartz (or tk)?
For now, in absolute desperation to make my tk/X11/OpenGL cortical surface programs usable on Mac OS X 10.10+, I pop up an xterm (using tcl/tk: exec xterm &), in front of an in-progress X11/tk/wish window, and then immediately kill the xterm (via tcl/tk: exec kill $pid). The uncovered in-progress tk/X11 window then draws itself almost instantly (vs. an excruciating 15-20 seconds). The drawing speedup is proportional to the area of the tk/X11 window covered my the xterm.
[apologies for previous duplicate post]
Here is a completely non-invasive way to demonstrate the massive increase in X11 drawing speed (20x) on Mac OS X 10.10+ caused by uncovering a drawing-in-progress X11 window. Requires command line compile tools. No install required. Doesn't touch anything outside of /tmp.
On Mac OS X 10.6.8, it takes 70 msec to draw 400 X11/tk buttons. On Mac OS X 10.12.5, running on same hardware, it takes 7-8 seconds to do the same thing, over 100x slower. The uncover hack gets us back to only 5x slower.
cheers, marty
download/compile tcl (no install)
cd /tmp curl -O ftp://ftp.tcl.tk/pub/tcl/tcl8_5/tcl8.5.18-src.tar.gz tar xvfz tcl8.5.18-src.tar.gz cd /tmp/tcl8.5.18/unix ./configure make
download/compile X11 tk (no install)
cd /tmp curl -O ftp://ftp.tcl.tk/pub/tcl/tcl8_5/tk8.5.18-src.tar.gz tar xvfz tk8.5.18-src.tar.gz cd /tmp/tk8.5.18/unix ./configure make
put following demo tcl/tk script into: /tmp/zz.tcl
=================== cut here =============================================
X11/tk/wish demo huge slowdown 10.10+ drawing speed, hack workaround
proc make400buttons { } { global argv if [lindex $argv 0] { ;# hack: 20x speedup on 10.12 (7sec->300msec) set pos +100+100 wm geom . $pos ;# must be aligned w/xterm else less speedup set pid [exec xterm -geom 172x44${pos} -e bash --norc &] after 50 ;# req'd else xterm not drawn in time (> ~10ms) lower . ;# speedup req's Xwin (exist OK, too) to get behind } for {set j 0} {$j < 20} {incr j} { ;# bottons:Aqua=130ms,10.6.8/X11=70ms frame .f$j pack .f$j -side top for {set i 0} {$i < 20} {incr i} { button .f
j.bi -text asdf pack .fj.bi -side left } } update idletasks ;# req'd timer, and to prevent early kill xterm if [lindex $argv 0] { ;# hack exec kill $pid raise . ;# must come after update idletasks } } if ![llength $argv] { puts "use: zz.tcl <0=nohack,1=hack>"; exit } puts "[expr [lindex [time make400buttons 1] 0] / 1000000.0] sec" ;# time =================== cut here =============================================start XQuartz.app
run demo WITHOUT uncover hack (takes 7-8 secs)
cd /tmp bash # if not already DYLD_LIBRARY_PATH=/tmp/tcl8.5.18/unix:/tmp/tk8.5.18/unix /tmp/tk8.5.18/unix/wish zz.tcl 0
run demo WITH uncover hack (about 300 msec)
cd /tmp bash # if not already DYLD_LIBRARY_PATH=/tmp/tcl8.5.18/unix:/tmp/tk8.5.18/unix /tmp/tk8.5.18/unix/wish zz.tcl 1
[sorry, forgot to include this in last post]
Setting XQuartz colors to 256:
XQuartz -> Preferences -> Output -> Colors: 256 Colors
results in the 400 tk buttons being draw in 130 msec instead of the 7-8 seconds it takes when colors are set to:
XQuartz -> Preferences -> Output -> Colors: From Display XQuartz -> Preferences -> Output -> Colors: Thousands XQuartz -> Preferences -> Output -> Colors: Millions
Unfortunately, 256 colors is useless for rendering shaded, floating point scientific data in color.
mentioned in issue #745 (closed)
marked #745 (closed) as a duplicate of this issue
Here is a new, hopeful observation about the long-standing MacOS 10.10+ drawing speed slowdown in Mac X11/tk!
I recently did a default upgrade of a mid-2012 MacBookPro laptop from MacOS 10.7 -> 10.12 -> 10.15. Then a default install of XQuartz 2.7.11.
Immediately after a reboot and login, XQuartz/X11/tk still runs extremely slowly, as reported above. This is exactly the same catastrophic more-than-100x slowness of XQuartz/X11/tk that happened starting with MacOS 10.10 (almost 10 sec for 400 buttons), when compared to 10.6.8 (70 msec for same).
However, simply logging out and logging back in results in virtually normal drawing speed! It's still a little slower than 10.6 :-} but perfectly acceptable. Dušan Peterc previously reported something similar one or two MacOS versions ago with an X11 app, fixed by logging in as a different user (see closed #745 (closed) above). The even simpler same-user, logout/login solution reliably works on MacOS 10.15 after multiple tries of:
- reboot
- login as marty -> slow
- logout/login marty -> fast
Unfortunately, after one sleep, it's back to sloooowww. However, this can be fixed again by logout/login (never any change in user, or multiple logins). There is no obvious difference in the DISPLAY var, which looks something like this in both fast and slow cases:
DISPLAY=/private/tmp/com.apple.launchd.ygR7418f7H/org.macosforge.xquartz:0
At first glance, the fact that X11/tk can run at full speed doesn't seem like something that would require completely rewriting XQuartz (or changing to xcb).
- I can confirm that the logout/login trick posted by @msereno results in a significant speedup.
- I also found that the latest version of
xorg-server(1.20.6) appears to be faster than the version included in XQuartz. The latest version of XQuartz (2.7.11) contains an outdated version ofxorg-server(1.18.*). - Using the latest Xorg-server and logging out and logging in again gives the best performance. So the bug is still there,
FYI: The latest version of
xorg-servercan be installed from source via MacPorts. (xorg-serveris not available via Brew.)sudo port install xorg-serverThis will install
/Applications/MacPorts/X11.app, which can be used instead of XQuartz.Edited by Hendrik WoutersHello,
I think I've encountered this same issue, with Motif applications exhibiting extremely slow drawing of menus and such. After some analysis of XQuartz, it seems like the core problem is due to an interaction between the closed-source libXplugin and the Core Graphics/Skylight graphics system.
As a workaround, I've attached a patch that decreases the number of flushes that occur after drawing operations, which has been very helpful in making my applications more usable.
removed bugzilla label
