Optimize picking

[pjcozzi]

The fix for #583 slows down the fragment shader for picking because it executes the full fragment shader for materials. If we know a material doesn't have any transparent parts (and doesn't write depth in the future), we can just use a simple pass-through shader.

[pjcozzi]

This will also optimize other passes like glow (e.g., a single bit mask) and shadow/depth pre-pass (depth only).

[pjcozzi]

We should also better document the performance costs of Scene.pick (rendering the scene), and encourage users to only call it once from their app. If need be, we could cache the result inside Scene.pick for when the objects/time doesn't change, but it would be a lot of bookkeeping to implement at this level.

[pjcozzi]

FYI...the bottleneck is, of course, in readPixels blocking while the GPU's pipeline flushes. In Open Philly Globe, readPixels is 40% of the profile when the Septa or Pedestrian Count layer is on and the mouse is moving. I'm not sure how much we can do about this without asynchronous readbacks using PBOs.

[pjcozzi]

With WebGL 2.0, we can also use MRT to render the pick buffer in the same pass as the color. CC #797

[billwritescode]

Any thoughts on addressing this? Noticing that gl.readPixels (via scene.pick) is chewing up CPU time: http://cesiumjs.org/releases/1.30/Apps/Sandcastle/?src=Hello%20World.html&label=Showcases&gist=09ea27d7643dceaacded4fe1f31a9471

[pjcozzi]

@billwritescode the biggest win will come from not stalling the CPU and starving the GPU with WebGL's readPixels. I think this is possible with WebGL 2, #797, and we'll investigate when we ramp up WebGL 2.