Page MenuHomePhabricator

Experimental QML support is inflexible and inefficient
Closed, WontfixPublic

Description

The current QVTKQuickItem implementation uses the Qt Quick integration approach of painting the VTK scene to the screen before the QSG[1]. This has a few significant drawbacks:

  • You must remember that Qt Quick stacking order does not apply to QVTKQuickItem instances in your Qt Quick application. So doing something as simple as drawing a solid black rectangle for the application background no longer works.
  • No item properties (other than x, y, width, height) can be applied or animated via Qt Quick. So fading out a view port during layout changes or animating a left-right or top-bottom flip of the viewport are not possible.
  • The QSG optimizations to repaint items only when necessary cannot be applied to QVTKQuickItem instances. So if you have, say, a pulsing animation that is not superimposed over any VTK viewport, the QSG will still re-render all the VTK viewports for every frame of the 60 FPS pulsing animation.

[1] http://qt-project.org/doc/qt-5/qtquick-visualcanvas-scenegraph.html

Event Timeline

I have a work-in-progress solution here that addresses this issue by rendering VTK to an OpenGL Framebuffer Object (FBO) and sharing that FBO with Qt Quick using QQuickFramebufferObject:

https://github.com/nocnokneo/MITK/tree/bug-18393-qml-rendering-improvements

This is working well except for:

  • It has only been extensively tested on a v2014.09-based version of MITK. I rebased the changes to the current MITK master on Sep 19, and was seeing some weird rendering issues when rendering to both 2D renderers and 3D renderers.
  • There is a memory leak when changing the slice of a 2D renderer on the order of about 1MB per 2D renderer slice change. I haven't been able to track this one down yet, but I have one good lead: the memory leak only happens when you also have a 3D renderer.

One additional note: Run applications with environment variable QML_BAD_GUI_RENDER_LOOP=1 in order to use single-threaded Qt Quick rendering so that you don't need to worry about the thread safety problems, which is a separate issue (T18394)

Is anyone still working on this?

I'm not working on it, but I know there are several stakeholders who are very much still interested in it.

kislinsk claimed this task.
kislinsk added a subscriber: kislinsk.
This task was automatically closed because it wasn't updated at least since July 2016 (over 2 years). Please re-open this task if you think that it is still relevant. This most probably means that you will resolve it.