Bug 93430

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.

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.