Created attachment 120573 [details] 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.
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.
Yep. Hopefully someone will come along and start working on libxcwm and XtoQ at some point, but it looks like there's nobody interested in working on the long-term solution.
I can confirm that the latest version of XQuartz 2.7.9 continues to draw 14-20 times slower on multiple macs (either integrated or extra card graphics) than on a virtual RHEL box running on the same mac at the same time, drawing the same data.
Yep, bugs don't fix themselves. =/
What's needed in those libraries? Is it a debug issue or a re-write? Does someone just need to re-compile or something simple?
No, it is not something simple.
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.
[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.b$i -text asdf pack .f$j.b$i -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.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/188.
I can confirm that till now XQuartz is still very very slow on macOS Mojave that I had to create a virtual machine running Ubuntu and then run X2Go client in that virtual machine and it's even hell lot faster than the native app on macOS.
XQuartz SLOWNESS HACK! 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. I show only opening of menus by passing the mouse over menu title, but main slowness is actually in resizing windows. Other operations work normally, but use interface is too slow fully productive use. https://www.youtube.com/watch?v=kld-KcUI0Ds 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. IT RUNS AT FULL SPEED!!! Same program, same computer, same versions of software. It was running like this before El Capitan when it became slow. This demonstrates that some Apple bug prevents the software from working normally, either in XQuartz, or at lower level. But it also shows that it could run at full speed. The only problem is that after some time (can't figure out what is triggering it), it becomes slow again. You can make it fast again if you logout and login (but still keeping the other session), without shutting down the computer. This apparently resets the graphics subsystem and cleans the "slow" system state. It is really awkward way of working, and it is hard to advocate with normal users. It is totally counter-intuitive, that software runs better if it has less memory and graphics resources (since they are used by the other session). If someone wants to try this with the software which is used in the video, you can get it here. https://www.arahne.si/learn-support/software-demo/installing-arahweave-demo-on-mac-os-x/ Otherwise try it with your software. I have tried it on many Mac computers of various generations (macbooks, imacs, mac mini, over 20 computers) and it was faster on all of them. Please share your ideas about solving the slowness bug in definitive manner.
Hi Dusan. I did just that back in 2016. Please see my post above if you are interested in working on a solution to replace the XQuartz DDX with Xorg and a compositing window manager.
Hello Jeremy, I do not have the resources and/or knowledge to fix low level X to Quartz interaction. But I am willing to contribute financially towards a solution. Maybe somebody else is also willing to chip in. I do not know how big is the project for this fix. You can contact me privately about it at dusan peterc at gmail, if you wish. Intuitively, as a hack on top of hack, would it be possible to write a small program, which resets the graphics system in the same way as logout, so that it would put the graphics system back in the fast state? Like on Linux KDE, where window manager was crashing constantly, and eventually programmers implemented restart after crash, instead of fixing the bugs ;-)
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/745.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.