Slow drawing over X11 / remote display¶
When you run the Understand GUI on a Linux host and view it over a forwarded X11 connection
(e.g. ssh -X), drawing can feel sluggish. The GUI is optimized for drawing on a local display;
sending every drawing operation across the network adds latency, and graph-heavy views make it worse.
The old -graphicssystem native flag is gone
Older SciTools notes suggest launching with understand -graphicssystem native to speed up an
exported display. That option belonged to a much older Qt version and no longer exists in
current Understand — passing it has no effect. Understand today runs on the Qt xcb (X11)
platform plugin and exposes no in-application switch to change its rendering path for remote
displays. Use the approaches below instead.
What actually helps¶
- Run analysis headless; keep the GUI local. For remote/CI work, do the heavy lifting with the
undcommand line on the remote host and open the resulting.undin a locally running GUI. Raw X11 forwarding is the slow part; avoiding it removes the bottleneck. - Use a remoting protocol built for it. X2Go, NX, or a VNC session composite the screen on the
remote side and stream it efficiently, which is far faster than raw X11 forwarding for a graphical
app. Prefer these over
ssh -Xfor interactive use. - Enable compression on the forward if you must use X11:
ssh -XCturns on compression, which helps on slow links (it does not eliminate per-operation latency). - Reduce what has to be drawn. Large graphs are the most expensive thing to render remotely. Close big graph windows you aren't using and keep individual graphs smaller — see performance on a large codebase for related guidance.