Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ModelViewTransform2.create* is called 10 times in this simulation #292

Closed
samreid opened this issue Dec 20, 2018 · 8 comments
Closed

ModelViewTransform2.create* is called 10 times in this simulation #292

samreid opened this issue Dec 20, 2018 · 8 comments

Comments

@samreid
Copy link
Member

samreid commented Dec 20, 2018

Inspired by #264, I observed that ModelViewTransform2.create* is called 10 times in this simulation. Many of these are duplicates and it would be good to isolate them. It seems the appropriate place to track them is in each Scene. But the problem is at the moment Scene is "model only". Once the view is constructed and we know the wave area bounds, we could create the transforms and set them to the Scenes. This seems a plausible approach but I'm not sure whether it is optimal. @pixelzoom what do you recommend?

@pixelzoom
Copy link
Contributor

pixelzoom commented Dec 20, 2018

These 2 calls to ModelViewTransform2.createRectangleMapping look suspicious to me:

BarrierNode:

// @private - View width for one cell
this.cellWidth = ModelViewTransform2.createRectangleMapping( scene.lattice.visibleBounds, viewBounds )
  .modelToViewDeltaX( 1 );

TheoryInterferenceOverlay:

const cellWidth = ModelViewTransform2.createRectangleMapping( scene.lattice.visibleBounds, viewBounds )
  .modelToViewDeltaX( 1 );

These look like the same transform, and the same cellWidth. Should this be computed elsewhere Should/could this transform be replaced by one the 3 transforms identified in implementation-notes.md?

The call in TheoryInterferenceOverlay occurs inside of {function} updateLines. Can it be moved outside of updateLines, so that it's computed once? Or does it really need to be recomputed each time updateLines is called?

(CM: edited the above.)

@pixelzoom
Copy link
Contributor

pixelzoom commented Dec 20, 2018

This call in WaveInterferenceUtils.getWaterDropX also seems out of place:

const transform = ModelViewTransform2.createRectangleMapping( waterSceneLatticeBounds, waveAreaViewBounds );

Is it really necessary to compute a transform each time getWaterDropX is called? Why aren't we using one of the 3 transforms identified in implementation-notes.md?

@samreid
Copy link
Member Author

samreid commented Dec 20, 2018

I'm planning to coalesce these. It appropriate to store them on the Scene? If not there, then where should they be stored?

@pixelzoom
Copy link
Contributor

implementation-notes.md says:

There are 3 coordinate frames:

  • view coordinates
  • lattice coordinates (integer), with damping regions
  • Scene-specific physical coordinates (such as cm or nm)

There are 3 coordinate frames. What are the transform relationships? The names used in the code aren't very helpful -- I see transform, modelViewTransform, modelToLatticeTransform, and latticeToViewTransform. The last 2 are the only ones that I can easily correlate to the 3 coordinate frames identified in implementation-notes.md. And the ones identified above for cellWidth are never given names.

@samreid
Copy link
Member Author

samreid commented Dec 20, 2018

Should I take a first pass at factoring these out, storing them in Scene.js after the view is created, then reassigning to you for review?

@pixelzoom
Copy link
Contributor

pixelzoom commented Dec 20, 2018

Scene sounds like an appropriate place to store these transforms. In most of my sims, I've stored ModelViewTransform2 instances in the model, typically instantiated in the model container's constructor. The exception to that would be when creating the transform has to occur after ScreenView creation.

@pixelzoom pixelzoom removed their assignment Dec 20, 2018
@samreid
Copy link
Member Author

samreid commented Jan 2, 2019

Proposed fix committed, please review.

@pixelzoom
Copy link
Contributor

Looks great, much clearer. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants