Builder/Viewer: loading a large system blocks the window long enough for GNOME's 'not responding' dialog #343

Activity

1. ohlincha commented on Oct 15, 2026

   

   ohlincha

   on Oct 15, 2026

   CollaboratorAuthor

   More actions

   Rotation of the 10,236-atom system on Linux with XWayland frame sync off (merged build): it still stutters, and Andy describes it as "rubber banding": the view seems to fall back and catch up. The cause is in the viewer's own drawing, not the compositor. Two candidates, to be told apart by a frame-by-frame video analysis:

   • a stale camera drawn by a second redraw path (the view moves backwards for a frame);
   • mouse motion coalesced after slow frames (the view only jumps forwards).
2. ohlincha commented on Oct 15, 2026

   

   ohlincha

   on Oct 15, 2026

   CollaboratorAuthor

   More actions

   Video measurement, merged build with frame sync off (Viewer, GROMACS minimisation of the 10,236-atom system, Geometry Step Plots panel open): 301 distinct frames in 10.5 s, mean 35 ms between them, 10 stalls over 100 ms, the longest 0.92 s. Before the fix: 14 stalls, longest 0.6 s. Frame sync was not the cause. Frames around the 0.43 s stall are too small at video resolution to tell forward from backward motion. Next step: profile a scripted rotation headlessly (perf on the Viewer under Xvfb) to see what takes the long frames, e.g. a full scene rebuild, bond regeneration or the step plot redrawing.
3. ohlincha

   added 2 commits that reference this issue on Oct 15, 2026

   Viewer: drop the low-detail drag mode again (#343)

   ...

   c97bf90

   Viewer: ECCE_DEBUG_CAMERA=<file> logs the camera of every redraw (#343)

   ...

   4ee0169
4. ohlincha commented on Oct 15, 2026

   

   ohlincha

   on Oct 15, 2026

   CollaboratorAuthor

   More actions

   Frame-by-frame analysis of four rotation recordings on niobium (GNOME Wayland, XWayland), 10,236-atom system:

   • The rough motion is an old frame reappearing. A distinct frame is often pixel-identical (mean difference < 1 grey level) to the frame two steps earlier, and then the motion continues: 16 times in 10 s zoomed in, 19 in 20 s zoomed out, and 23 in 18 s with ECCE_FRAME_SYNC=1. GTK frame sync (Wayland: typed text not drawn in name prompts again (New Calculation/Project/Study), and Builder pane resize freezes #339) is therefore not the cause.
   • A new frame arrives about every 0.13-0.15 s zoomed out.
   • Drawing spheres and cylinders at low detail while dragging (45b6e38) gave 1.8x on llvmpipe, but no visible change on the real GPU. It was reverted in c97bf90.
   • The front-buffer branch in SoWxRenderArea::redraw(), which swaps before drawing, is never enabled in ECCE, so it is ruled out.

   Next: ECCE_DEBUG_CAMERA=<file> (4ee0169) logs the camera orientation at every redraw. If the logged camera also steps back, a redraw uses an old camera, which is a bug in ECCE. If it only moves forward, the display stack is presenting an old buffer.
5. ohlincha commented on Oct 15, 2026

   

   ohlincha

   on Oct 15, 2026

   CollaboratorAuthor

   More actions

   Camera log (ECCE_DEBUG_CAMERA, 4ee0169) together with a recording of the same rotation:

   • ECCE never draws an old camera. There were 190 redraws, 122 of them with a moving camera. No step reverses direction, and no camera equals the one two redraws back.
   • The recording still shows 12 frames that are pixel copies of the frame before last (22 s). The old frame is therefore put back on screen below ECCE.
   • The machine: NVIDIA GeForce RTX 3050 with the proprietary 550.163.01 driver (Debian 13), XWayland 24.1.6, GNOME on Wayland. The 550 driver predates NVIDIA's explicit-sync support for XWayland (driver 555 and later, with XWayland 24.1 or later). Without it, GL frames from X11 programs under XWayland can be presented out of order. This fits what the video shows.
   • Separately, 67 of the 190 redraws drew an unchanged camera. That is wasted work at about 150 ms per frame for this system, and it is ECCE's own to remove.

   What follows:

   1. The jump-back is not an ECCE bug. It should not occur under an Xorg session, on 555+ drivers, on other GPUs, or on Windows/macOS. To be confirmed on an Xorg session.
   2. ECCE should skip redraws whose camera and scene are unchanged.
   3. The slow frames (about 150 ms for 10k atoms on an RTX 3050) come from moiv drawing every sphere in immediate mode. That belongs with the Coin3D/look work (Port the viewer to Coin3D (9.0) #166/Modernise the look: platform-native chrome, icons and plots; viewer after Coin3D #210).