Feature/color module

[meganrm]

Problem

347

Solution

I moved all the functions in visGeometry into a colorHandling class. In the process I also simplified the colorChanges which was an array, but we're only ever sending in one colorChange at a time. I updated https://github.com/simularium/simularium-website/pull/432 for this change too.

VisGeometry still has some color handling functions to unite the color with the visAgent, but it now only deals with colors by their names (no indices).

Type of change

Please delete options that are not relevant.

• New feature (non-breaking change which adds functionality)
• This change requires updated or new tests

Steps to Verify:

1. npm start
2. change an agent color using the drop downs.

[github-actions[bot]]

jest coverage report 🧪

Total coverage

Status	Category	Percentage	Covered / Total
🔴	Statements	40.73% (-5.13% 🔻)	1997/4902
🔴	Branches	44.26%	829/1873
🔴	Functions	37.79% (-5.69% 🔻)	412/1090
🔴	Lines	40.94% (-4.91% 🔻)	1911/4667

Status of coverage: 🟢 - ok, 🟡 - slightly more than threshold, 🔴 - under the threshold

Show new covered files 🌑

### Coverage of new files | Status | Filename | Statements | Branches | Functions | Lines | | :----: | :-------------- | :--------- | :------- | :-------- | :------ | | 🟡 | ColorHandler.ts | 67.64% | 75% | 62.06% | 66.66% | > Status of coverage: 🟢 - ok, 🟡 - slightly more than threshold, 🔴 - under the threshold

Show files with reduced coverage 🔻

### Reduced coverage | Status | Filename | Statements | Branches | Functions | Lines | | :----: | :------------------------ | :------------------ | :----------------- | :------------------ | :------------------ | | 🟡 | src | 77.98% (-1.83% 🔻) | 69.09% | 50% (-5.26% 🔻) | 78.43% (-1.96% 🔻) | | 🟢 | constants.ts | 82.35% (-11.76% 🔻) | 100% | 57.14% (-28.57% 🔻) | 81.25% (-12.5% 🔻) | | 🔴 | index.ts | 7.82% (-18.32% 🔻) | 7.56% (-4.74% 🔻) | 5.83% (-13.71% 🔻) | 7.79% (-18.3% 🔻) | | 🟡 | src/simularium | 62.47% | 60.17% | 51.73% | 63.37% | | 🟢 | SelectionInterface.ts | 95% | 86.04% | 95.23% | 95.48% | | 🔴 | src/visGeometry | 21.98% (-8.01% 🔻) | 23.2% | 28.03% (-4.27% 🔻) | 21.86% (-8.23% 🔻) | | 🔴 | GeometryStore.ts | 50.51% | 37.37% (-1.01% 🔻) | 63.41% | 49.73% | | 🔴 | src/visGeometry/rendering | 40.97% (-10% 🔻) | 65.27% (-1.23% 🔻) | 32.23% (-17.58% 🔻) | 41.49% (-8.94% 🔻) | | 🟡 | CompositePass.ts | 60% (-17.5% 🔻) | 75% (-5% 🔻) | 25% (-37.5% 🔻) | 62.16% (-13.51% 🔻) | | 🟡 | ContourPass.ts | 58.53% (-9.76% 🔻) | 83.33% | 23.52% (-23.53% 🔻) | 60.52% (-5.26% 🔻) | | 🟡 | DrawBufferPass.ts | 66.66% (-11.11% 🔻) | 83.33% | 33.33% (-33.33% 🔻) | 69.69% (-6.06% 🔻) | | 🔴 | GBufferPass.ts | 40% (-12.3% 🔻) | 75% | 36.36% (-36.36% 🔻) | 41.66% (-10% 🔻) | | 🔴 | GaussianBlur.ts | 34.28% (-40% 🔻) | 68.18% (-9.09% 🔻) | 22.22% (-50% 🔻) | 35.38% (-36.92% 🔻) | | 🔴 | HitTestHelper.ts | 55% (-22.5% 🔻) | 77.77% | 44.44% (-33.33% 🔻) | 56.75% (-21.62% 🔻) | | 🔴 | InstancedFiber.ts | 17.04% (-2.27% 🔻) | 56% | 14.28% (-5.72% 🔻) | 16.56% (-2.37% 🔻) | | 🔴 | LegacyRenderer.ts | 25.25% (-5.05% 🔻) | 33.33% | 29.41% (-11.76% 🔻) | 24.46% (-5.32% 🔻) | | 🟢 | PDBGBufferShaders.ts | 93.33% (-3.33% 🔻) | 77.77% | 71.42% (-14.29% 🔻) | 96.29% (-3.71% 🔻) | | 🟡 | RenderToBuffer.ts | 63.88% (-27.78% 🔻) | 70% (-10% 🔻) | 44.44% (-33.33% 🔻) | 66.66% (-27.27% 🔻) | | 🟡 | SSAO.ts | 66.66% (-11.11% 🔻) | 83.33% | 40% (-40% 🔻) | 69.69% (-6.06% 🔻) | | 🔴 | SimulariumRenderer.ts | 22.75% (-26.9% 🔻) | 75% | 15.38% (-23.08% 🔻) | 22.85% (-25% 🔻) | > Status of coverage: 🟢 - ok, 🟡 - slightly more than threshold, 🔴 - under the threshold

[toloudis]

About the change to only accept a single color at a time, I think we used to have in mind bulk color changes like "palettes". That's the only reason I can remember ever needing to change multiple colors in one function call in an optimized way. (And of course we never did it)

[meganrm]

About the change to only accept a single color at a time, I think we used to have in mind bulk color changes like "palettes". That's the only reason I can remember ever needing to change multiple colors in one function call in an optimized way. (And of course we never did it)

Yeah, I think in that case we would wipe everything out, ie, re-init the colorHandler with the new pallet, and then just call 'setInitialColors' again.