I noticed that TBrowser is now taking a long time to load upon creation, either with TBrowser tb
or new TBrowser
In case it’s relevant, I’m using ROOT 6.22 (I have the same issue with 6.24) on CentOS 7; I compiled the package from source using GCC 10.2. I’m running ROOT remotely, connecting to the CentOS 7 server with a Macintosh running Mac OS 10.14.6 and the Terminal app, with X11 emulation provided by XQuartz 2.8.1.
The issue seems to be that TBrowser is scanning my entire directory hierarchy to display all the directories, and their sibling directories, from the base / through to the directory in which I start root. During this time, TBrowser seems to be working on constructing the folder display on the left-hand side and hasn’t even started displaying X11 widgets on the right-hand side.
During the time the TBrowser window is being constructed, while the ROOT prompt (e.g., root [1] shows up, the interpreter is unresponsive. Only when the TBrowser has fully finished its internal graphics setup does the interpreter become responsive again.
The delay is on the order of a minute. It’s not terrible, but it’s annoying. While I don’t use the TBrowser often, I’m going to be teaching my annual ROOT tutorial to the Columbia University summer students and they’ll be instructed to use it a lot. You know how impatient kids are; an unresponsive browser will leave them with the impression that ROOT isn’t any good and they’ll retreat to Python.
Is there some option to the TBrowser to suppress the directory hierarchy display until the user specifically requests it?
Try to change the value of Browser.ExpandDirectories in the ${ROOTSYS}/etc/system.rootrc or in your your (custom) ${HOME}/.rootrc from yes to no, as shown below:
# Set the ExpandDirectories option to "no" to prevent expanding
# the parent directory tree (for example on nfs)
Browser.ExpandDirectories no
Thanks bellenot. Unfortunately, while that suggestion worked in the sense that it did exactly I asked for, it turns out that the large directory hierarchy was not the main reason for TBrowser’s slow response. It still took about 45 seconds for the interpreter to respond. During most of that time, the full range of X11 widgets on the TBrowser were not displayed. I’ve attached a screenshot. Note how there’s no text (yet) in the Command tab and the text areas within that tab are not yet bordered.
I gave it a try, and the TBrowser popped up immediately using VNC, with no noticeable delays. So the issue isn’t with ROOT, but with X11 over the network.
I’d still appreciate any advice anyone can offer, but I have to acknowledge that this is not a ROOT problem. I may have to find solutions on my own.
A simple web search on “XQuartz” slow shows that this is a known issue with XQuartz. A suggested solution is to set XQuartz to 256 colors in its preferences. Since I don’t need detailed shading in my work, that would be an acceptable solution. I noticed that when I used VNC I got a limited color palette (CentOS 7’s fancy GNOME desktop pattern was just a stair-step contour of color) but that doesn’t bother me.
I tried the 256-color solution on my Mac. While the TBrowser starts to draw quickly and normally, its window disappears, because XQuartz has crashed. Then the following message endlessly repeats in the interpreter:
Warning in <TGClient::GetColorByName>: couldn't retrieve color #000000.
Please close any other application, like netscape, that might exhaust
the colormap and start ROOT again
When I try Ctrl-C to break out of the loop, the loop continues. When I type .q in the hope of quitting the interpreter, I get:
The interpreter is then completely unresponsive. I have to close the Terminal window to exit the session.
I know very little about the mechanics of X11. But even if one of the colors in the TBrowser was outside the 256-color range, why would there be such a dramatic crash?
The problem is (also) that XQuartz has a much harder time on macOS these days. And X11 was never meant to be a network GUI system You should be able to configure VNC in a way that things work nicely - even a more generous number of colors will not slow things down noticeably. (The limit is generally latency, not bandwidth.)
The X11 color map is shared between all the running applications therefore
256 colors is really very small. As the error message tells you, TGClient is not able to find an free color to display (some part of) the GUI. Can you define a bigger number ?
From Display (the default)
256 colors
Thousands
Millions
256 colors gives the results I describe above. “Thousands” worked once and failed once (same as 256); from what you said, that probably had to do with the colors I used elsewhere on my Macintosh display (though TBrowser was the only X-Window open in all these cases). “Millions” always works. But with both “Thousands” and “Millions”, the TBrowser display was still quite slow.
Again, I’m not an X11, but I’ll comment that the TGClient message did not appear until after XQuartz had crashed, and then repeated endlessly. Could that error reflect that XQuartz had crashed and therefore nothing could be displayed? My (possibly incorrect) reasoning is that ‘color #000000’ is black, and seems like to have already been in any likely color map.
While VNC is a good solution for me personally, I’m teaching a class on ROOT for students. This year (for obvious reasons) they’re all going to connect remotely. With VNC, I’d have to teach them all how to do ssh tunneling (from Macs, MS-Windows, and Linux) and make sure their ~/.vnc/config files are set up correctly, plus avoid collisions from them all choosing the same port for their VNC server. And I’d be teaching this to people who’ve never typed ls on a command line before!
It’s much simpler to say “install XQuartz on Macs, install mobaXterm on MS-Windows, with Linux you’re ready” than to go through all of the VNC overhead just to see a histogram on a screen.
Yes, I know about Jupyter, and I’ve installed a JupyterHub server at Nevis Labs. But there’s no TBrowser, FitPanel, or TreeViewer in Jupyter. Those are very handy tools for ROOT beginners, and so I choose to start them off with “bare” ROOT before wrapping it within Jupyter.
YES! That did it! The TBrowser is zippy! Woo-hoo! Thank you, Wile_E_Coyote!
Since this setting is not the default, what am I giving up by doing this? A quick web search suggests that I’m giving up text anti-aliasing, which I can easily do without.
You should be able to configure VNC in a way that things work nicely - even a more generous number of colors will not slow things down noticeably. (The limit is generally latency, not bandwidth.)