Open pixelzoom opened 1 month ago
Using Sprites or CanvasNode for photons seems problematic.
The maximum number of photos that exist at any time is only 21. So the performance gain from using Sprites or CanvasNode is probably close to zero.
There will be a big memory footprint increase by using Sprites. There ~400 unique colors for photons, each of which would require a SpriteImage (a PhotonNode converted to Canvas). Like VisibleColor (see createColorTable
), we'd want to cache a SpriteImage for each color, and that's a relatively large cache. CanvasNode would probably not require a cache, but drawing photons using the Canvas API will be more complicated than the current PhotonNode implementation.
So... Big increase in memory and code complexity, for little/no performance gain.
Change the serialization of photons to the approach used in faradays-electromagnetic-lab. See for example
HeavyParticle.HeavyParticleIO
. This will eliminate the need to use PhetioGroup. Note that there are 4 subclasses of Particle: Electron, Neutron, Proton, and Photon. Photon is the only subclass that has dynamic instances and additional state, so it is the only subclass that requires serialization.This will also require changing the model and rendering approach for the collection of photons. In faradays-electromagnetic-lab, see IdealGasLawParticleSystem and ParticlesNode.
The model will contain
public readonly photons: Photons[]
, which will be serialized asphotons: ReferenceArrayIO( Photon.PhotonIO )
.The view will be something like
class PhotonsNode extends Sprites
. We'll probably want to cache SpriteInstances for each wavelength.