It is an option, but it's currently on by default. I can modify this. This was a "first effort" approach for generic hover labels in rendered views. There may be other strategies that may work in tandem with or replace this approach in the future.<div>
<div><div><br></div><div>Jeff<br><br><div class="gmail_quote">On Wed, Sep 9, 2009 at 11:59 AM, Moreland, Kenneth <span dir="ltr"><<a href="mailto:kmorel@sandia.gov">kmorel@sandia.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div>
<font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt">In general, the idea of having a second render in the still render (effectively doubling the time) is troubling. If you have a lot of geometry that takes a while to render (which is not uncommon in a 3D view), the added rendering time is not acceptable.<br>
<br>
Is this behavior an option and is it off by default?<br>
<br>
-Ken<div class="im"><br>
<br>
<br>
On 9/9/09 9:37 AM, "Jeff Baumes" <<a href="http://jeff.baumes@kitware.com" target="_blank">jeff.baumes@kitware.com</a>> wrote:<br>
<br>
</div></span></font><blockquote><div class="im"><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt">Basically yes. The exception is the render caused when the actual hover text changes and the scene needs to be re-rendered, in which case the pick render is not performed. The problem is knowing when a render caused any pipeline updates or camera changes, which are the cases where you need to re-generate the pick map. BTW the cached pick map is also used for drag-selections.<br>
<br>
Thinking about it, it would probably be better to wait for the first "mouse dwell" or drag-selection to update the pick map, I'll make a note of that.<br>
<br>
Jeff<br>
<br>
On Wed, Sep 9, 2009 at 11:27 AM, Moreland, Kenneth <<a href="http://kmorel@sandia.gov" target="_blank">kmorel@sandia.gov</a>> wrote:<br>
</span></font></div><blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt"><div class="im">Does that mean every still render is actually rendered twice with the second one basically a pick render?<br>
<br>
-Ken<br>
<br>
<br>
<br></div><div class="im">
On 9/9/09 9:04 AM, "Jeff Baumes" <<a href="http://jeff.baumes@kitware.com" target="_blank">jeff.baumes@kitware.com</a> <<a href="http://jeff.baumes@kitware.com" target="_blank">http://jeff.baumes@kitware.com</a>> > wrote:<br>
<br>
</div></span></font><div class="im"><blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt">I've just checked in a change that allows improved hover support in vtkRenderView subclasses.<br>
<br>
After each render (except during interaction), the view automatically takes a "snapshot" of what is currently rendered in a special render mode that maps pixel locations particular actors and cells. When the user's mouse stops over a cell, the render view looks up the hovered cell in the map and sends it to its representations to possibly produce a hover label. Representations manage the pipleline/mappers/actors for displaying a particular type of data in a view. They implement support for hover queries by overriding GetHoverTextInternal().<br>
<br>
This is currently implemented in vtkRenderedGraphRepresentation, where the user may select the vertex and edge hover arrays.<br>
<br>
The view also allows the hover labels not to be rendered with OpenGL, but invokes a HoverEvent when the hover label changes. This would allow an application to capture these events and use real native tooltips (e.g. with Qt) to show the hover labels.<br>
<br>
Jeff<br>
<br>
<br>
</span></font></blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt"><br>
</span></font></div><font size="2"><font face="Consolas, Courier New, Courier"><span style="font-size:10pt"><div class="im"><br>
**** Kenneth Moreland<br>
*** Sandia National Laboratories<br>
*********** <br></div>
*** *** *** email: <a href="http://kmorel@sandia.gov" target="_blank">kmorel@sandia.gov</a> <<a href="http://kmorel@sandia.gov" target="_blank">http://kmorel@sandia.gov</a>> <br><div class="im">
** *** ** phone: (505) 844-8919<br>
*** web: <a href="http://www.cs.unm.edu/~kmorel" target="_blank">http://www.cs.unm.edu/~kmorel</a><br>
</div></span></font></font><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt"><br>
</span></font></blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt"><br>
<br>
<br>
</span></font></blockquote><div class="im"><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt"><br>
</span></font><font size="2"><font face="Consolas, Courier New, Courier"><span style="font-size:10pt"><br>
**** Kenneth Moreland<br>
*** Sandia National Laboratories<br>
*********** <br>
*** *** *** email: <a href="http://kmorel@sandia.gov" target="_blank">kmorel@sandia.gov</a><br>
** *** ** phone: (505) 844-8919<br>
*** web: <a href="http://www.cs.unm.edu/~kmorel" target="_blank">http://www.cs.unm.edu/~kmorel</a><br>
</span></font></font><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt"><br>
</span></font>
</div></div>
</blockquote></div><br><br clear="all"><br>-- <br>Jeff Baumes, Ph.D.<br>R&D Engineer, Kitware Inc.<br>(518) 881-4932<br><a href="mailto:jeff.baumes@kitware.com">jeff.baumes@kitware.com</a><br>
</div></div></div>