Hi, Unfortunately, I do not have a rule how to avoid VTK render updates on invisible widgets. Actually, I never encountered that problem before and we already had people implementing different/multiple editors (for comparing images) and there is also the QmitkMITKSurfaceMaterialEditorView view which contains a separate QmitkRenderWindow.
On 11/07/2011 05:12 PM, Clarkson, Matt wrote: > However, I'm facing the following problem. If VTK tries to render before the > Qt widget is visible, then on a Mac you get an "Invalid drawable" error and > the application keeps going, but on Linux, you get an X windows error > message, and the application crashes. > > BUT. Any view (subclass of QmitkFunctionality, or berry::QtViewPart) can > call mitk::RenderingManager::GetInstance()->RequestUpdateAll() any time it > wants. Also, any view derived from QmitkFunctionality as opposed to > berry::QtViewPart will tend to open the QmitkStdMultiWidgetEditor by default, > even if it doesn't really need it. By this I mean, something like the > datamanager plugin should not really care about whether the > QmitkStdMultiWidgetEditor is open or not, as it only needs to manage the > datastore, and doesn't care about the visualisation). I agree that the dependency of some views on the QmitkStdMultiWidgetEditor is a design issue (the datamanager however does not have such a dependency). > So, it seems difficult to stop VTK doing a Render on any windows before the > widget is drawn on-screen, and I'm not sure how I should be preventing it. > Qt filters on the QmitkRenderWindow can squash PaintEvents, but it wouldnt > stop the mitk::RenderingManager. > So currently my Editor is creating a number (say 2x2) of QmitkRenderWindow, > and then when you change the number of rows and columns will dynamically > allocate new widgets and add them to the layout. Adding things to layouts > tends to trigger paint events. > > An alternative might be to instantiate the right number of widgets and > show/hide them, but the problem still seems to exist, as each time you add > them to a layout, you get paint events that you aren't ready for. > It seems that MITK is currently working nicely because there is only 1 editor > with rendering windows, so they are all visible at the same point. The QmitkStdMultiWidgetEditor also supports a predefined set of layouts and allows switching between them. We had no problems with it so far. Maybe you can find out what the difference to your current approach is. You might also define your own default perspective to avoid having views shown at startup which trigger the instantiation of the QmitkStdMultiWidgetEditor. > Any ideas? I think it's more philosophical guidance I'm after so that I head > in the right general direction. > Sorry, but I'm afraid I cannot be of more help here... - Sascha ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ mitk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mitk-users
