drillPick bug with targetFrameRate set

[mramato]

1. Bring up the Sandcastle picking example. (Bring up the debugger too because Chrome will hang otherwise).
2. Add viewer.targetFrameRate = 6 to the example and run it.
3. Start the drill-down picking example and move the mouse over the geometries that appear.
4. Chrome will quickly freeze, hit break in the debugger manually (failure to do so will cause Chrome to become completely unresponsive).
5. Keep stepping out until you are in Scene.pick

The problem is that Scene.drillPick is stuck in an infinite loop because even though it's turning off the show property of the top-most primitive, Scene.pick is still returning it as the picked primitive. It looks like we're just re-rendering the same seen over and over again instead of taking into account the fact that drillPick turned off one of the primitives.

Reported via the forum

Not sure if this is related to #2942

[bagnell]

I tracked this to setting the scissor test. The correct scissor rectangle is not getting cleared causing the same object to be picked. If you follow Matt's instructions and break here, the scissorTest.rectangle will be different than what is set (which you can query with gl.getParameter(WebGLRenderingContext.SCISSOR_BOX)).

@lilleyse confirmed that this doesn't happen on his Mac. Maybe it's an ANGLE only issue. Do we want to support clearing with the scissor test set? There is more overhead when we don't clear the entire buffer when using ANGLE.

[pjcozzi]

Do we want to support clearing with the scissor test set?

Probably fine. I doubt the overhead is significant compared to everything else.