[vtk-developers] When calling vtkWidgetRepresentation::BuildRepresentation() ?

[Julien Finet]

Hi,

Short story: When should BuildRepresentation() be called ?

Long story:
I was facing a rendering issue
with vtkOrientedPolygonalHandleRepresentation3D. The handle was not being
rendered until I moved the camera to a special orientation.
The issue was that the widget representation actor was being culled by the
renderer which prevented any rendering from happening. And only a rendering
(e.g. RenderOpaqueGeometry()) could update the actor position
via BuildRepresentation().

Browsing through the code, it seems that it is being called at different
places:
 a) when a display property is being called (e.g.
vtkSplineRepresentation::SetClosed)
 b) when bounds are being called (e.g. vtkLineRepresentation::GetBounds())
 c) after widgetInteraction is called (e.g.
vtkBorderRepresentation::WidgetInteraction()
 d) when rendering is being called (e.g. vtkProp3DButtonRepresentation::
RenderOpaqueGeometry())
 e) By the widget (e.g. vtkSliderWidget::AnimateSlider(),
vtkAngleWidget::MoveAction()). It seems to be at the same time than c)
Did I miss something ?

Here are critics against each solution:
a) seems a bit against the idea that BuildRepresentation() compresses all
the Modified() events and creates/refresh the representation when all the
changes are done.
b) Do we know for sure GetBounds() is being called by the renderer before
displaying any vtkProp ?
c) What if the representation has no interaction ? (processing of events
being OFF)
d) As explained in my long story, it is too late to refresh the
representation. (Rendering may never be called if the representation is not
built')
e) Same as d)
Do you disagree with my critics ? Did I forget anything obvious ?

It seems that b) (in GetBounds()) is the only valid location. Would you
agree ?

Thanks for those who read through my long email :-)
Julien.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140823/2d3688b8/attachment-0002.html>