﻿id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	blockedby	blocking	notify_on_close	platform	project
2355	Suggestion: track visible atoms/ribbons/bonds on C++ side	Tristan Croll	Eric Pettersen	"For big models, there's currently a fairly large fixed overhead to redrawing even when very few atoms are shown. For 4v9o (four ribosomes, just under a million atoms), if I set the lighting to simple and hide all but one atom, then if `m` is the model:

{{{
%timeit m._update_graphics()
104 ms ± 16.7 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)
}}}

Most of this can be explained by just four calls:
{{{
%timeit m.chain_trace_atoms()
29.7 ms ± 2.12 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)
%timeit m.atoms.visibles
12.6 ms ± 857 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
%timeit m.bonds.showns
22.6 ms ± 1.71 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)
%timeit m.atoms.num_selected
14.9 ms ± 2.61 ms per loop (mean ± std. dev. of 7 runs, 100 loops each)
}}}

... all for essentially the same reason: they're looping over all residues, atoms bonds or atoms (respectively) in the model at each call.

The problem gets compounded when I add ISOLDE's live validation markup, which also needs to know which atoms/bonds are visible (Rama needs to know about backbone atom visibility, Rota display depends on visibility of the CA-CB bond).

What I'd like to suggest is that this information gets cached on the C++ side. That is, `AtomicStructure` would provide new methods, e.g. `visible_atoms`,'shown_bonds',`ribbon_displays` providing the cached data, with any changes with the possibility to change it flagging the need to recalculate on next call. This would avoid any increase of complexity on the Python side - just a trivial adjustment from e.g. `m.atoms.visibles` to `m.visible_atoms` while vastly cutting down computational cost in these situations - the loop over all objects only gets run once per relevant change, rather than one or more times per coordinate change. Additionally, it would allow for easy future parallelisation of these tasks if you wanted to go down that route."	defect	closed	moderate		Core		not a bug		Tom Goddard				all	ChimeraX
