Max molecules correct value makes long simulation loading

[andrey-zelenkov]

MAX_MOLECULES value (view/workspace/magnifier/MagnifierMoleculesLayer.js) in the original sim is equal to 200. When I set correct value it takes long time to start. I've added some optimizations for generating of molecules but is still takes approximately 30 seconds on PC to start with correct value. Could you check if there is an error in the application assembly?

[jbphet]

I looked at this, and don't have an immediate solution. PhET will do some additional investigation and update this ticket with what we figure out.

[jbphet]

When asked to look at this, @pixelzoom said:

This is symptomatic of the fact that joist currently instantiates all screens at startup. Add option to defer instantiation until the first time that a screen is visited, or as a 'background task'. Also consider instantiation cost during design - for example, if 'Molecules' were not the default selection, then it would fairly easy to defer instantiation until the first time that the feature is made visible. (Related issue: Is MLL updating this view only when it's visible?) In the meantime, live with the long startup time.

[andrey-zelenkov]

I've fixed bug with updating view (now it's update only when visible), but it's still take long time to load. Tried to wrap adding magnifier into setTimeout(...,0) (for defer instantiation): sim loaded pretty fast, but adding magnifier still takes long time (we can see first screen, but can't select level). May be will help adding to magnifier only molecules nessesary for current solvent, not show/hide mode. Clip-path probably try to clip groups even if it's not visible than when we try to add new group it forced render others (it explains the power-law dependence on the number of atoms). Thank you for advise! I will inform you after checking results.

[pixelzoom]

MagnifierMoleculesLayer.setMolecules is called 40+ times on startup. It should be called no more than twice (once for each screen).

I also see many unexplained property notifications occurring at startup. For example, add console.log to AqueousSolution (see below) and you'll see that it's called 26 times, sometime with value=Infinity. A certain amount of notification is expected while the sim reaches initial equilibrium, but this seems excessive. And if other properties are doing the same thing, it would contribute to the long startup time.

 this.property( 'H3O' ).link( function( value ) {
      console.log( 'H3O value=' + value );
      self.ph = -Math.round( 100 * Math.log( value ) / Math.LN10 ) / 100;
    } );

[pixelzoom]

Status:

MLL made changes to eliminate unnecessary updates during startup and when invisible, and I've verified those changes. But the number of molecules is still set at 50 (it should be 200) and startup time on my MacPro with local web server is ~7 seconds.

If I change max molecules to 200, the sim takes ~50 seconds to start on my MacPro with local web server. To speed this up, I recommend using an approach similar to what I did in ph-scale.RatioNode. Convert molecules to images, then draw them directly to scenery.CanvasNode using context.drawImage.

How does PhET want to proceed with this issue?

[pixelzoom]

@ariel-phet would like me to address this, no further work required MLL.

[pixelzoom]

Canvas-based implementation is done. 200 molecules maximum. It's wicked fast on iPad2.

[pixelzoom]

Also very responsive on Nexus 7.

Startup times are now typical of other sims. Here are approximate times starting up from localhost: Mac Pro: 3 seconds MacBook Pro: 3 seconds iPad2: 7 second Nexus 7: 13 seconds

[pixelzoom]

The only issue I see now is that the molecules rendered to canvas look fuzzy/jagged compared to the molecules rendered with scenery (e.g., in the reaction equations.) See screenshot below. Compare the molecules in the magnifier (canvas) to those in the equations (scenery).

@jonathanolson do you have any suggestion on how to improve the quality? Implementation is in acid-base-solutions.MagnifierNode.

[jonathanolson]

The images of molecules placed into MagnifierNode's moleculeImages are low-resolution (1 pixel per 1 local-coordinate unit square).

Until Scenery 0.2 handles this as an option to Canvas caching, I'd recommend picking a scaling factor, scaling up the nodes you pass to toImage, and then applying the inverse of the factor when drawing the images.

Let me know if you need any assistance with this because of the deadline (or if I should run the fix myself).

Additionally, iPad 3 will use the lower-resolution Canvas for the particles unless we specify "fullResolution: true" in rendererOptions. If performance is an issue, we should probably not set fullResolution.

[pixelzoom]

Thanks, will do the scaling. Performance is an issue, so will not use a full-res canvas.

[pixelzoom]

Store images as 2x their needed size, scale down when drawing to canvas, remember to also double the radius used for computing random points inside the magnifier. Looks much nicer, screen shot below, compare to the fuzzy one above.

[pixelzoom]

All work on this is complete. Startup time is now typical, we are drawing 200 max molecules (same as Java version) and the images look nice.

Closing.