Excessive time spent in update phase of frame rendering when GPU clamping is enabled for annotation geometry

[otherjason]

Full details are at this forum thread:

http://forum.osgearth.org/Excessive-time-in-spent-in-event-phase-of-frame-rendering-with-latest-trunk-td7582352.html

Here is a summary of the problem.

• I have "a lot" (approximately 100) EllipseNode annotations in my scene. I am using the AnnotationEventHandler class to catch hover-enter, hover-leave, and click events on each annotation.
• I'm using the latest trunk version of osgEarth. I did not see the problem in revision 71903c8b60798fa2152dddb066f4884b6725daac from late May.
• The trigger seems to be enabling of GPU clamping for the ellipses. If I use "scene" clamping mode, I don't see the problem; the event phase completes quickly (typically much less than 1 msec) and on-demand rendering mode work properly.

If I change the annotations to use "gpu" clamping mode, then two things happen: the event phase of the frame rendering process balloons in time to ~20-25 msec, and on-demand frame rendering stops working. It seems that OSG believes that there is continually an event that is waiting to be handled, and thus frames get rendered continually.

The duration spent in the event phase in this failure mode seems to be linear in the number of ellipses that are marked as visible. If I hide some of them (using osg::Node::setNodeMask()), then the time spent in the event phase of the frame loop decreases accordingly. If I hide them all, then the event processing goes down to a low number (~0.2 msec), but on-demand rendering is still broken.

[gwaldron]

Jason, do you have a drop-in .cpp example I can use to test this? If so we can try to resolve it before 2.5. Thanks.

[otherjason]

I haven't been able to generate a simple example that demonstrates the problem yet. I will attempt to do so and will add it here if I find one.

[gwaldron]

old.