Compute zone triangle mask in C++ thread

[tic20@…]

I'm not sure what is being requested here. To mask a map isn't a copy being made? A thread could make the 3D array, and when it returns that becomes a new Volume model, or replaces the array in an existing Volume model. Need clarification on what the problem is.

Begin forwarded message:

From: Tristan Croll
Subject: Re: ISOLDE and ChimeraX plan for the future
Date: May 4, 2020 at 3:24:17 PM PDT
To: Tom Goddard

Hi Tom,

...

Also moderately (but probably not *horribly*) difficult: a full double-buffering treatment for map contouring and masking. In Clipper I've put quite a bit of work into speeding up masking (and loading of the fresh data when a crystallographic map is recalculated), but while the contouring happens in a separate thread the masking operations don't, so there's still a really noticeable hitch in framerate for anything bigger than a tiny region. There's no reason the whole process couldn't be threaded, other than the time it takes to actually set it up.

[Tristan Croll]

Sorry, should have been more clear. I was referring to the *triangle* 
mask for visualisation (i.e. `surface zone`). Looking at Clipper, what 
happens currently when the position/shape of the region being visualised 
changes is as follows:

- If a crystallographic map, the necessary data is fetched from Clipper. 
This is parallelised (since the symmetry lookups make it slower than 
just straightforward indexing) but blocks the main thread.
- The surface calculation is then triggered 
(clipper.maps.map_handler_base.FastVolumeSurface). This pushes the 
actual contouring calculation away to (a) C++ thread(s), so there's 
essentially no hold-up of the main thread - the new visualisation just 
appears a few frames later.
- When the surface calculation is done, the triangles then need to be 
masked down to give the final visualisation. While I've put a fair bit 
of work into making this faster (see clipper.maps.mask_handler.py and 
clipper.maps._maps.mask.cpp), it still happens in the main thread and 
typically takes 5-10 ms per map. For a small region covering a single 
cryo-EM map that's generally just fine, but for larger regions and/or 
multiple maps the lag becomes very noticeable. So that would be the next 
most obvious thing to push out to a separate thread.

On 2020-05-05 00:51, ChimeraX wrote:

[goddard@…]

So triangle mask calculation needs to go in a separate thread.  Doesn't sound like "double buffering".  You have a list of triangles and atom positions and a calculation finds the triangles near the atoms.  Sounds like just porting some existing ISOLDE code to a C++ thread.  Should this ticket be retitled "Compute zone triangle mask in C++ thread"?

[Tristan Croll]

Sounds fair to me.

On 2020-05-05 18:25, ChimeraX wrote: