[WebGL] Experiment: Render the entire sim in WebGL

[samreid]

Moved from phetsims/fluid-pressure-and-flow#251

In order to estimate an upper bound on performance and provide a way to incrementally add support for WebGL for different node types, I am experimenting with rendering the entire sim in WebGL. Components that do not have a WebGL node can be temporarily rendered as rectangles or equivalent. This issue is to track progress and keep notes on what's been done on this investigation.

Work is being done in branch "experimental-webgl-support".

[samreid]

I checked in the ability to render unknown nodes as rectangles or toCanvasNode image nodes in the branch above. toCanvasNode is coming out very fuzzy and at the wrong location!

[samreid]

I'm also experimenting with overrides in Text and Path that provide stubs for WebGL support. Perhaps this would be a better starting point for adding more WebGL support a bit at a time? Numerous other changes were required to accommodate this, but may be good if we can get some of this into the ohtwo branch soon.

[samreid]

The other change I'd like to make to facilitate adding webgl support incrementally is to add scenery.bitmaskSupportsWebGL flags for all of the nodes for now and adding stubs for Path and Text (until they can be completed properly). For example, this would mean that rounded rectangles just render as square rectangles, for example. And we can incrementally add support for different node types while still seeing the entire sim render in a single WebGL canvas.

Thoughts @jonathanolson?

[samreid]

@jonathanolson & I discussed this over skype and concluded that scenery.bitmaskSuppotrsWebGL shouldn't be enabled by default in master or ohtwo, but that we could enable all of those bitmasks with a query parameter interpreted in joist. In the meantime I may push some intermediate progress to a branch.

[samreid]

I checked in intermediate progress and a list of all places scenery.bitmaskSupportsWebGL is required in the branch "webgl-bitmasks" above.

[samreid]

Status report from WebGLBlock.js (similar status report in PixiBlock.js)

/**
 * Handles a visual WebGL layer of drawables.  The WebGL system is designed to be modular, so that testing can
 * easily be done without scenery.  Hence WebGLBlock delegates most of its work to WebGLRenderer.
 *
 * STATUS REPORT
 * March 4 2015
 * WebGLBlock is in bad condition--it is a collection of prototypes and not ready for production code.  The best way to
 * see the status of WebGLBlock is to launch:
 * http://localhost/forces-and-motion-basics/forces-and-motion-basics_en.html?rootRenderer=webgl&screens=1
 *
 * Completed in this version of forces and motion: basics, with pixi
 * 1. Images are rendering, and are in the correct position
 * 2. 60fps while dragging on iPad3 (note that this could go down as we add other features like transparency, clipping, etc)
 * 3. Resizing is handled
 *
 * Issues in this version of forces and motion: basics, with pixi
 * 1. Z-ordering is incorrect
 * 2. Context loss is not handled
 * 3. Path is just rendering as SquareUnstrokedRectangle and not showing up
 * 4. Text is not showing up
 * 5. Alpha transparency is incorrect, see #397
 *
 * @author Jonathan Olson <[email protected]>
 * @author Sam Reid (PhET Interactive Simulations)
 * @author Sharfudeen Ashraf (For Ghent University)
 */

[jonathanolson]

I think a good medium-term solution is to have a "default" webgl renderer for everything that uses Canvas to render it, then have it added to the sprite-sheet.

Will need a good way to switch things between drawables for the same renderer (e.g. switching between non-rounded and rounded rectangles needs to trigger a switch between types of webgl drawables).

Combined with #49, we'd be able to render things much more efficiently.