[vtk-developers] glxMakeCurrent and Hardware Picking issue

[Mark Beall]

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