[vtkusers] Performance degradation due to pixel copy when performing off-screen rendering

[Clinton Stimpson]

I think the best way to overcome this is to use a QVTKWidget and 
implement a QVTKPaintEngine for it.  The sample code I posted a while 
back and gave to you does it this way.  However the QVTKPaintEngine in 
that sample is only partially implemented.  The simple pixel copy needs 
to be changed to draw with textures.

With this method, there won't be any pixel copying of the frame buffer, 
and no potentially slow offscreen rendering.  And, if you use a 
QGraphicsProxyWidget to embed Qt widgets into the VTK view, it would 
result in QVTKPaintEngine::drawPixmap being called.  The implementation 
of that should use textures to draw, and cache them.  Doing so would 
mean that most of the time, the image you want drawn is already in the 
video memory, and its very fast to add back to your VTK scene each its 
rendered.  The only time a texture would change is if the embedded 
QWidget changes in size, or if its contents change.

Clint

Elvis Dowson wrote:
> Hi Clint,
>                   I just noticed a fundamental flaw in implementations 
> that use pixel copy, such as the algorithm in QVTKWidget and the 
> QVTKGraphicsView class that I'm working on. Because we're using a 
> pixel copy algorithm to copy VTK rendered pixel data to a QWidget or 
> QGLWidget, the larger the active render window, the more pixels that 
> we have to copy, thus reducing the rendering rate for the VTK scene.
>
> In the current implementation, small window sizes are quite 
> interactive. However, my Mac Book Pro has a 1920x1600 resolution 
> screen and if I maximize the window, the rendering rate dramatically 
> drops to around 1 or 2 fps.
>
> How can we overcome this limitation? Will attempting to go the OpenGL 
> way and share an OpenGL rendering context with the QGLWidget be a 
> solution? Won't that utilize GPU hardware bit-blitting of pixel data 
> to the screen, for the final OpenGL rendered images?
>
> I'd just like to think of an alternate possibility and keep it ready. 
> I don't think I'm going to spend any more time in trying to get a 
> shared OpenGL rendering context to work. For the moment, I'm going to 
> stop with just pixel copy and get the interactor working in a 
> QGraphicsScene.
>
> In any case, do let me know what you think!
>
> Best regards,
>
> Elvis Dowson