[vtk-developers] New feature: improved hover support

Jeff Baumes jeff.baumes at kitware.com
Thu Sep 10 10:39:57 EDT 2009

> Picking the entire viewport during each still render is more appropriate
> for (1). (This is what vtkScenePicker does)

> Picking the entire viewport after each hover/delay may be more appropriate
> for (2).

I did look into vtkScenePicker, but did not want the hover text to be
updated so often, and there was tighter integration needed into how the
hardware selector and view interact. So I used vtkHardwareSelector directly
instead. Case 2 seems like the most common one, but perhaps we could support
other modes in the future.

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.
I just checked in a change for this. The extra render no longer happens at
each still render, but instead when the mouse hovers or selects for the
first time. Still renders cause a dirty flag to get set so the view knows
when a new pick render is needed. If hover events are off, and the selection
mode is set to "frustum" instead of "surface", pick renders will never

>>> Is this behavior an option and is it off by default?
It is now off by default.

Thanks for the feedback.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20090910/fbfacb76/attachment.html>

More information about the vtk-developers mailing list