Viewer: leaving Mulliken Charges shows half-restored, pale atom colours for ~2 s #258

9.0.0-alpha.10, Windows 10; also seen on Linux (Debian 13). After Mulliken Charges, choosing another property shows the molecule in wrong, washed-out colours for about 2 s. Example: NH₃ from an ORCA geometry optimisation, 60 fps screen recording.

Sequence

1. Mulliken Charges selected: the atoms are recoloured by charge in two visible steps. First N is blue and the H atoms partly blue; then the final charge colours (N red, H blue; colour bar −0.863 … 0.863).
2. MOs selected next: for about 2 s N is pale salmon (between the charge red and its normal colour) and the H atoms still have their blue charge colour.
3. Then the normal element colours (N blue, H white), once the MOs panel has finished building.

The Linux report (O pinkish for 2–3 s when choosing Geometry Step Plots or Geometry Trace) is very likely the same thing, with Mulliken Charges viewed just before.

Likely cause: leaving the charge view restores the atom colours only partly, or blends them, and a frame is rendered in that state. The final colours come only from the render after the next panel's (slow) construction, so the intermediate state stays on screen for as long as that takes.

Proposed fix

• Restore the element colours completely and at once when a colouring property is left (one scene update), before the next panel is built.
• Apply the charge colouring in one update as well (step 1 shows two).
• Test: a headless Builder script switching Mulliken Charges → MOs, reading back the atom materials (or rendering) after the switch; this was not reproducible by timing alone on Xvfb, so check the colours themselves.

Related: #255 (panels drawn over the viewer during property changes).