[vtk-developers] glxMakeCurrent and Hardware Picking issue

[Mark Beall]

Lisa,
Does the browser window get rendered like any other window (e.g.
by calling vtkRenderWindow::Render)?
If so, wouldn't everything work if at the start of rendering,
the render window saved the old context, set the current context
to what it wants it to be, then when it is done, changes it
back to what it was before. 
This actually wouldn't solve the hardware picking problem since 
there needs to be a means to not switch contexts, but it does
seem that it would put the context changes in the right place
and eliminate the need to check them each time an actor is 
rendered.

mark

On 6/14/01 11:50 AM Lisa S. Avila (lisa.avila at kitware.com) wrote:

>Hello Bob,
>
>The MakeCurrent() calls are necessary any time the pipeline might have 
>updated. A good example of why is the pipeline browser - if you use this 
>script it pops up another windows that graphically displays the pipeline, 
>and using start/end methods it displays the pipeline execution. That means 
>the graphics context is switching back/forth continually during a render.
>
>Yes, hardware picking does have its problems. We have discussed this in the 
>past and I think one of the proposed solutions was to have another render 
>method for picking that does not cause a pipeline update, and always 
>renders whatever was last rendered (for example, in the case of an LOD 
>actor or prop). This means moving all the Update calls into conditionals, 
>and only performing them for "active" rendering (not picking). This would 
>also allow the MakeCurrent calls to be conditional, since no other 
>MakeCurrent should be able to occur in picking mode.
>
>Of course, this is easy to say and probably tricky to do...
>
>
>Lisa
>
>
>
>At 11:18 AM 6/14/2001, obara wrote:
>>Hi Folks,
>>
>>As you may know Simmetrix has been looking into the performance issue of
>>VTK when large numbers of actors are involved.  One of the things that
>>were noticed was vtkOpenGLActor calls glxMakeCurrent every time the actor
>>(the call is actually in the mapper) is rendered.
>>
>>Besides this possibly being a performance issue, this also introduces a
>>problem when using hardware picking.  When using the default picker (in
>>3.2) with QT I noticed that the OpenGL QT widget complains that
>>glxMakeCurrent fails when a pick is performed (in fact there are multiple
>>messages) - The problem is that hardware picking requires OpenGL's
>>rendering mode to be GL_SELECT and when in that mode glxMakeCurrent will
>>fail.
>>
>>I'm not too sure why during a normal render process the actor is calling
>>glxMakeCurrent to begin with (Maybe it depends on a result from a
>>different window) - but in general I'm not sure that people do this and
>>this approach will fail if hardware picking is being done.
>>
>>As a side issue:  When doing a pick, eventually the mapper's render()
>>function is called and at least in the case of vtkOpenGLPolyDataMapper
>>the graphical representation could be modified since RenderPiece() checks
>>the modification information - this could be somewhat problematic if the
>>user was doing a pick involving an animated scene since the object that
>>was under the cursor before may have "moved" due to the fact that the
>>picking process caused an update to the scene.
>>
>>Any Ideas/Comments?
>>
>>Bob
>>
>>Robert M. O'Bara
>>Senior Software Engineer
>>Simmetrix Inc.
>>1223 Peoples Ave.
>>Troy, NY 12180
>>
>>Lab: (518) 276-2867
>>Main Office: (518) 276-2729
>>
>>
>>
>>_______________________________________________
>>vtk-developers mailing list
>>vtk-developers at public.kitware.com
>>http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
>_______________________________________________
>vtk-developers mailing list
>vtk-developers at public.kitware.com
>http://public.kitware.com/mailman/listinfo/vtk-developers