struts command needs up-to-date graphics

[Eric Pettersen]

In a script, if I change from a non-ribbon depiction to a ribbon depiction and then call a "struts" command, I get a bad number of struts added unless I wait 1 first, e.g. "open 3fx2 autostyle false; preset 'initial styles' cartoon; struts @ca" produces 163 struts whereas "open 3fx2; struts @ca" produces 28.

[Tom Goddard]

The problem is that the preset hides atoms and shows the ribbon but the backbone atoms ribbon hide bit is not set until the ribbon is actually drawn. Struts is only considers connectivity between displayed or hidden atoms.

[Tom Goddard]

It is a bit strange that the ribbon code sets ribbon hide bits on backbone atoms when it is computing the graphics. Generally the graphics update should not change any attributes of the atoms / bonds / residues -- it is only intended to compute sets of vertices and triangles and colors for rendering based on the current model settings. That suggests that changing the ribbon show attribute of a ribbon probably should set the atom ribbon hide bits for backbone atoms at the same time. But it is not simple. The atom ribbon hide bits are only set if a ribbon is shown for the residue. Setting ribbon shown on a non-polymer residue, for instance a water, does not set atom hide bits. Even polymer residues may not have a ribbon shown because they lack the guide atom needed and those do not have atom hide bits set. So it makes some sense that the atom hide bits are set when the ribbon is actually computed, because that is where the code decides which residues will have ribbon graphics.

[Tom Goddard]

Maybe the proper way to remedy this bug and its relatives is to do a graphics update (ie rebuild vertices, triangles, colors) after every command in a script, but don't actually render a frame since that would completely change movie script behavior. This will slow script execution down, potentially a lot, for instance a generated script that sets each atom color with a separate command would update all the colors every command since one atom color change causes rebuilding the sphere colors for all atoms in that structure.

[Tom Goddard]

Another example where updating graphics every command would be extremely costly is if Python code looped over all atoms and ran a command that hid an atom. As each atom is hidden the graphics for all atoms of the structure would be rebuilt. This is not a common script, but the error observed in this bug is also not common, and we may be exchanging one hard to debug problem (too many struts) for another hard to debug problem (why is the script unusably slow).

Maybe it would be best to think about how to make this struts problem easier for a script developer to debug since the work-around (adding a wait 1 command) is very simple if you know to do it.

The source of this bug is we are doing an optimization by only updating the ribbon when needed instead of when the change of ribbon display is requested, and this optimization screws up the order of operations when the next command depends on the ribbon update already having happened. An unpleasant fix is that any command like struts that might depend on such delayed actions needs to be aware of this possibility and update the ribbon before it proceeds. No one is going to realize they need to put such code in until a bug is reported.

[Eric Pettersen]

Editing a structure has a similar problem for IDATM types: don't want to recompute them on every editing operation. The way that works is that there is a boolean in Structure that keeps track of whether the IDATM types are up to date. Editing the structure sets that boolean to false. Requesting an IDATM type checks the boolean, and if it's false the types get recomputed before the IDATM type is returned.

Perhaps a similar scheme could be adapted to ribbon display and hide bits?

[Tom Goddard]

That IDATM types approach sounds sensible. But in this case the atom hide bits are accessed by C++ and if they are out of date call a massive Python / C++ recalculation of the ribbon. I am not keen on having the C++ code call back into Python to do that. I think I will address this limited struts case for now. Struts is a bit strange in that where it puts struts depends on the current graphics since it wants to connect disconnected pieces. So I think it is is not unreasonable that the struts command make a call to assure the Structure graphics are up to date.

[Tom Goddard]

Fixed.

Made struts update structure graphics before computing connectivity.