While rotating the prisms under light rays, the rays seem to get broken or distorted at times. Some of the broken light rays are permanent on the screen (doesnt get reset as in second image below).

Please see images below for example -

As expected and similar to the Java sim, the performance with white light mode decreases significantly compared to the single color mode. It starts getting degraded more and more as more shapes, reflections, normal, multiple rays options are loaded. @ariel-phet, Request your direction on this.

There are several positional changes and size changes to be done across all three sims to replicate the mock-ups. Please refer to the attached images.

Intro sim -

Prisms sim -

More tools sim -

The performance in the Ray mode seems ok but the performance in wave mode needs to be improved.

Please see images below -

Time - graph plotter sensor boundaries to be adjusted for read out in wave mode. Please see image below.
The black probe is reading the wave although its outside wave and white probe is not reading the wave although its inside the wave.

Sometimes it is noticed that the rotation of the prism gets stuck for no specific reason even if there was a single prism. I couldn't find a step by step method to re-generate the scenario. Seems to happen more frequently for white light mode (although it happens in one color mode as well but less frequently). Please check.

See phetsims/beers-law-lab#86

Examples of anti pattern (not exhaustive):

IntensityMeter: this.value = new Property( NaN )
BendingLightView: var showRotationDragHandles = new Property( false );
BendingLightView: var showTranslationDragHandles = new Property( false );
LaserView: var wavelength = new Property( model.wavelengthPropertyProperty.value * 1E9 );

Cursor arrow should turn into a hand when over the protractor in the control panel. Observed during our March 11 meeting.

WaveWebGL rendering in Intro screen and MoreTools screen are one affecting others. Even though in both screens WaveWebGLNode instance is different .

The torch disappears for a moment while dragging the Time-Graph plotter in safari bowser on Mac.

1. The two arrows representing rotation are thicker and shorter in Java sim
2. The four arrows representing x-y translation in Java sim are -
   A. shorter, B. thinner and C. and origin of all the four arrows is centered on the torch

Please refer Java sim.

To replicate the issue -

1. Choose white light, multiple ray mode
2. Switch on the torch
3. Introducing any prism shape into the white light rays.

Notice the distortion of the middle white ray that happens somewhere in between the torch and prism.

I launched the sim with this query parameter stringTest=x and noticed a few strings that are not yet internationalized.

Tested on Windows 8 on Chrome

The sim becomes unusable after adding a few objects for the light to be refracted off, turning on settings i,e:
show normal
white light
show reflections
multiply rays

Performance becomes extremely poor and any interaction takes a minute for any response to be shown.
.

Don't know if this is intentional or not, but I noticed that when wave is selected for the laser view, the laser is not able to be dragged to 0 degrees from horizontal. It's stuck here:

As opposed to where it should be able to go:

Speed sensor z-order to be above the torch but below the time-graph plotter.

The red light ray thickness matches but for the white light ray, the thickness in the Javascript ported sim looks 1px thicker than the Java sim. Perhaps this could also be the reason for a more diffused dispersion - the rays suffering dispersion are not sharp unlike Java sim.

In Firefox browser, the single ray switch shows extended length of ray. Please see image below

The intensity sensor gets bigger when pressing "reset all", even if it had not been moved previously. It should remain the same size when reset all is pressed in that case. Here's a movie:

Please see the image below. The purple color doesnt fill up the entire medium space on firefox.

Starting on the More Tools tab:

1. Click the wave option for the laser view.
2. Turn on the laser.
3. Pause the sim.
4. Switch to either of the two other tabs.
5. Go back to the More Tools tab, and the wave will start moving while the sim is still paused.

I'm using Windows 8.1

I noticed that when finely selecting the wavelength of the light the borders between the two mediums will shift up vertically by a pixel or two. Look at the screenshot for proper setup.

Slow and Fast buttons currently seem to be non-functional.

On the intro tab, click the wave view of light and access the intensity meter. Notice that every time you move the intensity meter, the wave of light will not render properly.

Dragging the Intensity sensor on firefox causes color rending issues. Once this dragging is done, then
other related issues seem to appear - This white distortion doesnt get reset, Switching on the torch produces broken rays etc.,

Please see image below.

The speed sensor read out be 1.00 c like in Java sim. Currently it shows 1 c

I discussed wave view performance with @jonathanolson today and we concluded:

The approach that would yield the best performance would be to use WebGLNode and use a fragment shader that looks up the color for the pixel.
Then there would be 6 webgl triangles, 2 for each of the beams.
We could use charges-and-fields as an example (though it is doing double buffering, so it is a bit more complex)
Since canvas node cannot do repeating gradients, using canvasNode may be too slow here.
Instead, we should update scenery to make the Pattern transform mutable, and the gradient mutable, and render them using SVG. Tests could be done outside of scenery to see if this is practical before spending time working on this.

Single light mode - Ray doesn't change color on firefox. It only changes at the tip of the torch. Pls see image below -

We decided in phetsims/charges-and-fields#39 to deprecate constrainBounds and add a method to Bounds2 "closestPointTo".

This should be used in the future instead of ConstraintBounds.constrainLocation and eventually we should get rid of the file ConstraintBounds altogether.

Pls refere the highlighted box to see what this broken affect looks like.

I imagine we would like to place some limit on the amount of prisms of any given type the user can place on the screen? Otherwise I suspect there would be some performance issues. Related to #6

Design

• Design doc created (Date: 01/13/2015)
  • Make [email protected] owner, share with phet-team
  • Add to Master Doc List
• Legacy sim docs/info gathered
• Learning goals and standards identified (Date: 01/16/2015)
• Design concept complete (Date: 01/17/2015)
• Wireframes complete (Date: 01/17/2015)
• Mockups complete (Date: 01/23/2015)
  • Mockups checked for colorblind and greyscale
• Design doc sent for quote (Date: 01/19/2015)
• Visual and interaction review of first deliverable
• Interviews complete (Date: 02/17/2016)
  • Results reported to team
  • Notes pasted into design doc
  • Back-up of interviews
• Lead designer "sign off" (Date: 11/19/2015)
  • Performance acceptable
  • No new feature requests
• Pre-publication items
  • Screenshot (2048x1344, PNG, 32-bit color, browser chrome stripped)
  • Compatible activities
  • Accessories (keywords, categories, description, learning goals, related sims, NSDL)
  • Teacher guide
  • Update Gooru spreadsheet
  • Sim primer (Being tracked in #366)
  • Verify credits
• Add to Edmodo

Implementation

• Sim repo created (Date: 01/05/2015)
  • Collaborators added (such as 3rd party, QA team, designers, etc)
  • Sim added to active repos list in chipper
  • Sim suggestions doc reviewed
  • Unfuddle tickets reviewed
  • Existing sim tested for bugs, issues reported in repo
  • Port existing strings (IF ANY) and commit to the GitHub repo
  • Implementation details added to design spec
  • Paste snapshot of code review checklist into repo issue
• Initial development started (Date: 02/05/2015)
• Sim feature complete (Date: 05/15/2015)
• Code review complete (Date: 11/06/2015)
  • Code review checklist
  • Model description
• PhET tweaks after sim acceptance (Date: 12/10/2015)
• Published (Date: 12/23/2015)
  • Update repo README to published template

QA

• Dev testing complete (Date: 06/10/2015)
• First release candidate (Date: 12/18/2015)
• Sim accepted from third party (Date: 10/16/2015)
• Test matrix deemed complete

The reset all does not return the sim speed during wave emission to its default setting.

Seen on Win 7 and 8.1

I am trying to port the LightWaveNode to javascript. In the Java version, a cyclic GradientPaint is used for the alternating color pattern. What is the equivalent for this in Scenery?

I was building all sims, and the lint (auto-Java-ported bits) filled my scrollback.

1. Frequently there appears a sharp crest which is unlike the other crests in all the waves - incident wave, reflected wave and refracted wave.
2. In reflected wave, white and red lines appear occasionally

Protractor z-order should be on top of all the rays

I am currently testing on OSX 10.9.5. The sliders corresponding to indices of refraction does not function properly. When grabbing the slider node and lifting the cursor above the slider bar, the slider node will slide between the minimum and maximum values. After the node slides between 1.00 and 1.60 I noticed that if you click a position on the slider bar, the value of the index of refraction will not change until the user slides the slider node. Nothing severe, just thought I should report.

?ea enables the assertion testing. Currently the simulation fails with this assertion error:

Uncaught Error: Assertion failed: Text should be defined and non-null. Use the empty string if needed.
Error: Assertion failed: Text should be defined and non-null. Use the empty string if needed.
    at window.assertions.assertFunction (http://localhost:8080/assert/js/assert.js:22:13)
    at Text.inherit.setText (http://localhost:8080/scenery/js/nodes/Text.js?bust=1423659961879:99:25)
    at http://localhost:8080/bending-light/js/common/view/IntensityMeterNode.js?bust=1423659961879:118:17
    at Property.inherit.link (http://localhost:8080/axon/js/Property.js?bust=1423659961879:156:11)
    at new BodyNode (http://localhost:8080/bending-light/js/common/view/IntensityMeterNode.js?bust=1423659961879:117:36)
    at new IntensityMeterNode (http://localhost:8080/bending-light/js/common/view/IntensityMeterNode.js?bust=1423659961879:174:21)
    at new ToolboxNode (http://localhost:8080/bending-light/js/common/view/ToolboxNode.js?bust=1423659961879:62:30)
    at new IntroView (http://localhost:8080/bending-light/js/intro/view/IntroView.js?bust=1423659961879:121:24)
    at IntroScreen.Screen.call.backgroundColor [as createView] (http://localhost:8080/bending-light/js/intro/IntroScreen.js?bust=1423659961879:26:34)
    at http://localhost:8080/joist/js/Sim.js?bust=1423659961879:388:28

Please describe this branch and what the plans are for it.

Even though the simulation has not been fully completed or QA tested, we wanted to start the code review early, so that @samreid will be able to work on it before his leave begins. This will be the central issue for the code review, with sub-issues created and linked to this one or labeled with the "code-review" label. Also, in order to increase the efficiency, quality and standardization of our code reviews, we have created a code-review check list, available at https://github.com/phetsims/phet-info/blob/master/code_review_checklist.md. I'll paste it below and we can use it as a template for the review:

PhET code-review checklist

Build and Run Checks

• Does the sim pass jshint?
• Does the sim build without errors?
• Does the sim start up? (requirejs and built versions)
• Does the sim experience any assertion failures? (run with query parameter 'ea')
• Does the sim pass a scenery fuzzer test? (run with query parameter 'fuzzMouse')
• Are there any strings that are not being internationalized? (run with query parameter 'stringTest=x', you should see nothing but 'x' strings)
• Does the sim layout gracefully handle internationalized strings that are twice as long as the English strings? (run with query parameter 'stringTest=double')

Repository structure

• Are all required files and directories present?

  For a sim repository named “my-repo”, the general structure should look like this (where audio/ or images/ may be omitted if the sim doesn’t have those types of assets).

   my-repo/
      assets/
         my-repo-screenshot.png
      audio/
         license.txt
      doc/
         model.md
         implementation-notes.md
      images/
         license.txt
      js/
         my-repo-config.js
         my-repo-main.js
         version.js
      strings/
         my-repo-strings_en.json
      .gitignore
      my-repo_en.html
      Gruntfile.js
      LICENSE
      package.json
      README.md

For a common-code repository, the structure is similar, but some of the files and directories may not be present if the repo doesn’t have audio, images, strings, or a demo application.

• Is the js/ directory properly structured?

  All JavaScript source should be in the js/ directory. There should be a subdirectory for each screen (this also applies for single-screen sims). For a multi-screen sim, code shared by 2 or more screens should be in a js/common/ subdirectory. Model and view code should be in model/ and view/ subdirectories for each screen and common/. For example, for a sim with screens “Introduction” and “Custom”, the general directory structure should look like this:

   my-repo/
      js/
         common/
            model/
            view/
         custom
            model/
            view/
         introduction
            model/
            view/
         my-repo-config.js
         my-repo-main.js
         version.js

• Is there a file in assets/ for every file in audio/ and images/?
• Are all license.txt files populated? audio/license.txt and images/license.txt should enumerate all files in those directories. For the format of license.txt files, go here.
• Does the README.md format and content match PhET guidelines? Was it generated by grunt generate-published-README.md?
• Does Gruntfile.js point to chipper/js/grunt/Gruntfile.js?
• Are dependencies in package.json the same as js/*-config.js? Do they match what is actually used by the sim? (ie, no missing dependencies, no unused dependencies)
• Is the version identifier in package.json the same as js/version.js?
• Is the LICENSE file correct? (Generally GPL v3 for sims, MIT for common code, but there are exceptions to this.)
• Does .gitignore match other repositories?
• Does *-main.js follow PhET conventions? Does it contain correct credits (options.credits passed to Sim constructor)?
• Is the format of assets/*-screenshot.png correct? (2048x1344, PNG, 32-bit color) Has the browser chrome been stripped off of the screenshot?
• Are there git repository branches that are no longer used and should be pruned?

Coding conventions

• Does the code style meet PhET's code-style guidelines, as described in the “Coding Style Guidelines” section of "PhET Development Overview"?
• Is the code formatted according to PhET conventions? See phet-idea-code-style.xml for IntelliJ IDEA code style.

Documentation

• Are documentation conventions followed, as described in the “Coding Style Guidelines” section of the PhET Development Overview?
• Does model.md adequately describe the model, in terms appropriate for teachers?
• Does implementation-notes.md adequately describe the implementation, with an overview that will be useful to future maintainers? Issue in #111
• Are sim-specific query parameters (if any) identified and documented in one location?

Organization, Readability, Maintainability

• Does the organization and structure of the code make sense? Do the model and view contain types that you would expect (or guess!) by looking at the sim? Do the names of things correspond to the names that you see in the user interface?
• Are appropriate design patterns used?
• Is inheritance used where appropriate? Does the type hierarchy make sense?
• Is there any unnecessary coupling? (e.g., by passing large objects to constructors, or exposing unnecessary properties/functions)
• Are the source files reasonable in size? Scrutinize large files with too many responsibilities - can responsibilities be broken into smaller delegates?
• Are any significant chunks of code duplicated?
• Is there anything that should be generalized and migrated to common code?

Performance, Usability

• Does the sim perform as desired across the range of supported platforms? (eg, not too slow on slow platforms, not too fast on fast platforms). See #153
• If the sim uses WebGL, does it have a fallback? Does the fallback perform reasonably well? (run with query parameter 'webgl=false'). See #154
• Are UI components sufficiently responsive? (especially continuous UI components, such as sliders)
• Are pointer areas optimized, especially for touch? (run with query parameter 'showPointerAreas')
• Do pointer areas overlap? (run with query parameter 'showPointerAreas')

Memory Leaks

• Does a heap comparison using Chrome Developer Tools indicate a memory leak? (Describing this process is beyond the scope of this document.) #155
• Are there any leaks due to registration of AXON observers?
  • For each call to Property.link or PropertySet.link, is there a corresponding unlink, or documentation about why an unlink is unnecessary?
  • For each DerivedProperty or Multilink created, is there a corresponding detach, or documentation about why a detach is unnecessary?
  • For each common-code component (sun, scenery-phet, vegas, …) that opaquely registers an AXON observer, is there a call to that component’s dispose function, or documentation about why dispose is unnecessary?
• Are there any leaks due to registration of components with TOGETHER? together.addComponent should be accompanied by together.removeComponent or documented why removeComponent is unnecessary.

In Java sim the mouse cursor changes to hand while hovering on 1. Shapes, 2. Torch.

Need to replicate this in javascript sim as well

It is fairly easy to remove objects from the screen in view by the dragging of the object and re-sizing of window. This includes the prisms, tools, and laser pointer in the "Prism Break" scene.

When selecting wave mode with the chrome dev tools open, I see this error
TypeError: undefined is not a function

//IntroView.js line 280
lightWaves[ i ].step();

While making a common-code refactor in IntensityMeterNode, I noticed this buggy code:

intensityMeter.sensorPosition.reset();
intensityMeter.bodyPosition.reset();

intensityMeter is a PropertySet, and properties can't be accessed this way. If this code is reached, it will cause this error:

Uncaught TypeError: undefined is not a function

The correct code should be:

intensityMeter.sensorPositionProperty.reset();
intensityMeter.bodyPositionProperty.reset();

1. For large angles of incidence ( > 60 degrees or so), the incident light wave is broken at the medium separation line.

Pls see image below

Speed sensor boundaries to be adjusted for read out in wave mode. Please see image below.

Reset functionality should reset the angle of the torch to a default initial angle as per the java sim