[vtk-developers] glxMakeCurrent and Hardware Picking issue

[Lisa S. Avila]

Hello Mark,

It is still a bit more complicated than your example. That is because the 
context may change without a render being called so there are more places 
that this push/pop would have to occur. For example, grabbing the pixels 
from the screen, updating the camera, querying the depth buffer depth, etc. 
all cause context changes. Each of these operations would also need to do 
this push/pop.     I do think you have a good idea here - it can 
significantly reduce the number of context switches in the case of a large 
number of actors and no other render windows. Ken's new superclass (I think 
he is working on this now) for all OpenGL windows will help - it will be a 
superclass that can implement the push/pop functionality, and all 
operations that could potentially change the current context should be part 
of this class or a subclass of it.

Lisa



At 07:59 AM 6/15/2001, Mark Beall wrote:
>Hi Lisa,
>I don't think I explained myself correctly, let me try again.
>Here is what I understand happens for the case you're talking
>about (the pipeline browser), here renderWindow1 contains 1
>actor (actorA) , renderWindow2 is the pipeline browser, it
>has two actors (actor1 and actor2) and it's rendering is
>triggered during the update of actorA.
>
>renderWindow1 renders {
>   actorA renders {
>     actorA updates {
>       renderWindow2 renders {
>         actor1 renders {
>           actor1 updates
>           actor1 calls makeCurrent
>           actor1 draws
>         }
>         actor2 renders {
>           actor2 updates
>           actor2 calls makeCurrent
>           actor2 draws
>         }
>       }
>     actorA calls makeCurrent
>     actorA draws
>   }
>}
>
>If the above is substantially correct, then what I'm proposing is
>to change things so it does this:
>
>renderWindow1 renders {
>   renderWindow1.oldContext = current context
>   set current context to correct one for renderWindow1
>   actorA renders {
>     actorA updates {
>       renderWindow2 renders {
>         renderWindow2.oldContext = current context
>         set current context to correct one for renderWindow2
>         actor1 renders {
>           actor1 updates
>           actor1 draws
>         }
>         actor2 renders {
>           actor2 updates
>           actor2 draws
>         }
>         set current context to renderWindow2.oldContext
>       }
>     }
>     actorA draws
>   }
>   set current context to renderWindow1.oldContext
>}
>
>The important thing here is that each render window sets the context back
>to what it was before it rendered. This makes nesting them work without
>a problem.
>
>mark
>
>On 6/15/01 1:16 AM Lisa Sobierajski Avila (lisa.avila at kitware.com) wrote:
>
> >Hello Mark,
> >
> >At 06:47 PM 6/14/2001, Mark Beall wrote:
> >>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.
> >
> >
> >No, this does not work because the renders are actually intermingled. If
> >you have three actors in a renderer in a render window, plus you have the
> >pipeline browser then when render is called on the render window, actor A
> >is rendered, which means the mapper is updates and all connected filters
> >are update. Each mapper / filter update causes a render in another window.
> >This occurs AFTER the initial render started, and before actor A actually
> >renders.
> >
> >>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.
> >
> >There is no way to eliminate the check unless you eliminate the update. We
> >can add a special render-but-don't-update mode that won't check or do any
> >context switching - that also solves the pick problem (mostly).
> >
> >Lisa
> >
> >
> >_______________________________________________
> >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