When running Cadence Xcelium 26.03 on Rocky Linux 8.10 through VNC, parts of the GUI became corrupted. Menus and toolbars rendered incorrectly, and maximizing, switching to full screen, or resizing the window could leave broken or stale areas on the screen.
The fix in this environment was to change the VNC desktop session from a GNOME-based desktop to Xfce4. The problem did not occur when GNOME was used directly on the Rocky Linux host, so this was not simply a GNOME problem. It appeared only with the combination of a GNOME-based session and VNC rendering.
Test environment
- Operating system: Rocky Linux 8.10
- EDA tool: Cadence Xcelium 26.03
- VNC server: TigerVNC on Rocky Linux
- VNC client: UltraVNC Viewer on Windows 11
- Original desktop session: GNOME-based desktop
Changing the VNC server did not fix the issue. In contrast, using the same GNOME-based desktop directly on the physical host did not reproduce the corruption.
Symptoms
- Opening an Xcelium toolbar or menu caused parts of the GUI to overlap, disappear, or render incorrectly.
- Maximizing the application or entering full-screen mode triggered display corruption.
- Resizing the window left stale screen regions or incomplete repainting.
- The application could still respond, but the damaged display made normal work difficult.
What the comparison showed
| Condition | Result |
|---|---|
| GNOME-based desktop over VNC | GUI corruption occurred |
| GNOME-based desktop used directly on the host | Could not reproduce |
| Different VNC server | No improvement |
| Xfce4 over VNC | GUI corruption disappeared |
This makes an Xcelium-only bug or a TigerVNC-only bug less likely in this case. The evidence points to an interaction between the GNOME-based desktop rendering path and the VNC session.
The exact failing component was not isolated. It could involve the desktop shell, window manager, compositor, X11, or their interaction with VNC. Therefore, it would be inaccurate to claim that one specific GNOME component was proven to be defective. The reliable observation is that the issue occurred with GNOME over VNC, did not occur on the local host, and disappeared after switching the VNC session to Xfce4.
Solution: run Xfce4 in the VNC session
The following procedure shows the relevant Rocky Linux 8 steps. Back up your current VNC startup file and review the enabled repositories before making changes.
1. Enable PowerTools and EPEL
sudo dnf config-manager --set-enabled powertools
sudo dnf install -y epel-releasePowerTools is the Rocky Linux 8 repository name. On newer Rocky Linux major versions, the corresponding repository is called CRB.
2. Install Xfce
sudo dnf grouplist
sudo dnf groupinstall -y "Xfce"Confirm that the Xfce group appears in the group list before installing it. The Rocky Linux documentation also describes enabling the required repositories and installing the Xfce package group on Rocky Linux 8.
3. Start Xfce from ~/.vnc/xstartup
In the tested setup, the desktop launched by TigerVNC was changed by editing the per-user startup script at ~/.vnc/xstartup. First, back up the existing file and open it in an editor.
cp -a ~/.vnc/xstartup ~/.vnc/xstartup.bak
vi ~/.vnc/xstartupConfigure the file to start Xfce4:
#!/bin/sh
unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS
exec startxfce4Then ensure that the startup script is executable:
chmod +x ~/.vnc/xstartupStop and restart the VNC session for the display number in use, then reconnect from UltraVNC Viewer on Windows 11. The exact restart command depends on how TigerVNC was installed and how the display number is managed, so check the current service or session configuration first.
Result after switching to Xfce4
After reconnecting to an Xfce4 VNC session, the Xcelium 26.03 menus and toolbars rendered normally. Maximizing, full-screen mode, and window resizing no longer reproduced the display corruption.
EDA applications often use complex GUI layouts, waveform windows, and many frequently updated panels. If an EDA GUI works locally but becomes corrupted only through VNC, testing a lighter desktop environment such as Xfce4 is a useful diagnostic step before spending more time changing viewer encoding, color depth, or VNC server implementations.
Summary
- Xcelium 26.03 GUI corruption occurred on Rocky Linux 8.10 when a GNOME-based desktop was used through VNC.
- The issue did not reproduce when GNOME was used directly on the Rocky Linux host.
- Changing the VNC server did not solve the problem.
- Starting Xfce4 from
~/.vnc/xstartupsolved the display problem. - The lowest-level cause was not isolated, so the evidence supports a GNOME-and-VNC interaction rather than a proven bug in one specific component.
