Page MenuHomePhabricator

Unknown status: Bad performance after scrolling with mouse wheel
Closed, WontfixPublic


After scrolling in or out with the mouse wheel in the 3D-renderwindow (surfaces or points) the performance gets worse (best effect with big surfaces).

Event Timeline

Stadard 3D Interaction (Zooming, Moving, etv) should be exclusively handled by vtk, so if the "other interaction" is causing the problems, we might need to limit what we dispatch to this window. but my first guess would be its vtk related.

Could not reproduce the difference between scrolling and right click zooming.

Loaded some DICOM RT Structs, and interaction/visualization is extremely slow - i guess it is due to mapper implementation, as the countour is built up from a multitude of tubes.

I was able to reproduce this bug on my mac. We should further investigate this one for the upcoming release

We could reproduce this bug on Windows on the current master.

We are not sure whether this is a general vtk problem or somehow induced by MITK.

The next step would be:
Use an VTK only tutorial/example to test a problematic large dataset.

Nico, could you export the scene with the tube renderings where the bug occured as STL-file and add it as attachment here?

Current release is finished. Resetting target milestone

First problem: in standard3D renderwindow the HandleEvent method of mitk shouldn't be evoked because it triggers the slicenavigationcontroller which is useless in 3D. Only QVTKWidget::wheelEvent(we); should be called.
see QmitkRenderWindow::wheelEvent(QWheelEvent *we)
--> TODO: Test whether interactions in mitk still work with these modifications.

Second problem: VTK starts two consecutive render operations and we don't really know why...
see vtkInteractorStyleTrackballCamera::OnMouseWheelBackward()
both Dolly() and EndDolly() are called and invoking the rendering process.

patch for mousewheel interaction

Markus fixed the problem by bypassing the interaction pipeline (patch)
-> there is maybe a better long-term solution

Sandy, is there any update regarding this bug? Is it likely to fix it for the upcoming release? Can you please update the target milestone accordingly?

kislinsk lowered the priority of this task from High to Low.Oct 28 2016, 10:04 AM
kislinsk edited projects, added MITK; removed MITK (2016-11).
kislinsk claimed this task.
kislinsk added a project: Auto-closed.
kislinsk added a subscriber: kislinsk.

Hi there! 🙂

This task was auto-closed according to our Task Lifecycle Management.
Please follow this link for more information and don't forget that you are encouraged to reasonable re-open tasks to revive them. 🚑

Best wishes,
The MITK devs

kislinsk removed kislinsk as the assignee of this task.May 26 2020, 12:05 PM
kislinsk removed a subscriber: kislinsk.