molecular surface (+ any caps) does not update during atomic trajectory playback

[Elaine Meng]

open any atomic trajectory (e.g. open 1plx coordset true)
show surface
(can clip to show surface cap)
play trajectory, e.g. with slider interface "play" button
... no change in surface or its cap

[goddard@…]

We've gone over this one multiple times -- molecular surfaces currently do not update automatically for coordinate changes.  This is currently the intended behavior, but one we may want to change.  I believe there is another (possibly more than one) ticket for this.

[pett]

I have difficulty imagining any user not expecting the surface to update when the structure updates. I mean, the surface moves when the structure moves, right? Now, I can imagine wanting to *disable* updating for performance reasons in some usage situations, but having it disabled by default just seems wrong to me.

--Eric

[Tom Goddard]

Fixed.

Molecular surfaces now update when a coordinate set trajectory is played, or when atom coordinates change, or atoms are deleted.

When surfaces are colored to on a per-atom basis (e.g. rainbow, b-factor, ...) the surface maintains the coloring during trajectory playback and coordinate changes. But coloring is lost (replaced with single color) if atoms are deleted. This is a limitation of the current implementation that just keeps an array of colors -- when atoms are deleted the current code does not know which positions the deleted atoms were in the array.

[Tom Goddard]

Eric, I ran into a performance issue with atomic changes detecting which surfaces need updated. If a residue changes, say a rotamer change, or maybe a single chain is moved to fit density, then atomic changes has atom_reasons "coord changed" and modified_atoms() gives which atoms were involved. That is all good. But there is also a "coordset changed" reason in coordset_reasons() and modified_coordsets() in this case. When the code gets that change it does not know which atoms changed, so all chain surfaces need to be updated. This can be quite expensive when structures with dozens of chains have one chain changed. I'm not sure how to improve this situation. Maybe you have an idea. I currently made an ugly compromise where I assume that if I get "coord changed" and "coordset changed", I just ignore the "coordset changed" to give best performance. But that can give the wrong result, where a surface does not update.

[pett]

The only way you can get the "coordset changed" trigger _without_ "coord changed" is if the CoordSet::set_coords() C++ function is called, which is not exposed to Python and which nothing in our C++ layer currently calls. I'd say it would be safe for you to completely ignore the "coordset changed" trigger.