<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi,<div> I just went through the thread, and I just want to make sure that I have understood the situation correctly. I'm new to Qt and haven't used it before. </div><div><br></div><div><b>Question 01:</b> Is the approach that you have outlined, different from what the original Trolltech article talks about? </div><div><br></div><div>The Trolltech article talked about using a QGLWidget instead of the QWidget with QGraphicsView. </div><div><br></div><div>Now, QVTKWidget uses QWidget and not QGLWidget. QGLWidget has two options, one using a painter engine and the other using OpenGL. The current implementation of QVTKWidget copies RGBA pixel data to the rendering surface attached to QWidget. </div><div><br></div><div>In the sample code that you developed, you created a way to blend the pixels generated from Qt into VTK's render window. </div><div><br></div><div><b>Question 02: </b>Isn't there a performance overhead, plus future maintenance issue with respect to Trolltech improving the performance of their approach to be gained here, if you subclass QVTKWidget from QGLWidget and use OpenGL instead of the Painter engine? </div><div><br></div><div>Thus, one one hand, you can get rid of one level of indirection from the VTK side, and directly connect to the Qt supplied OpenGL rendering context, rather than adding one level of indirection by copying pixel data.</div><div><br></div><div>On the other hand, Trolltech may continue to improve the performance of their technique in subsequent releases, so if we stick to their suggestion of using QGLWidget with QGraphicsView, we will be compatible with and be able to take advantage of performance improvements with time. </div><div><br></div><div>So, can't we just locate where the generation of the VTK OpenGL commands end, just before generating the pixel data, and then pipe that to a QVTKWidget::drawBackground() method, instead of the current QVTKWidget::paintEvent() method?</div><div><br></div><div>Do you think this approach will improve the performance of the implementation?</div><div><br></div><div><br></div><div>Best regards,</div><div><br></div><div>Elvis Dowson</div><div><br></div><div><br><div><div>On Oct 15, 2008, at 8:23 PM, Clinton Stimpson wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "> <div><br></div><div>The solution is to implement a QPaintEngine for the QVTKWidget. Then its almost a drop-in replacement for QGLWidget in those examples you're looking at.</div><div><br></div><div>This has been discussed before, and here's the end of that last thread.</div><div><a href="http://www.vtk.org/pipermail/vtkusers/2008-August/096696.html">http://www.vtk.org/pipermail/vtkusers/2008-August/096696.html</a></div><div>There's some rudimentary sample code included that demonstrates what you're after.</div><div><br></div><div>The sample code needs to be improved before it can be included into VTK, and preferably without calling OpenGL directly. Hopefully VTK has enough abstract apis to make that possible. I'd work on it some more, but haven't got the resources to.</div><div><br></div><div>Clint</div><br><div><div>On Oct 15, 2008, at 10:00 AM, <a href="mailto:vtkusers-request@vtk.org">vtkusers-request@vtk.org</a> wrote:</div></div></div></blockquote></div><br></div></body></html>