Page MenuHomePhabricator

RFD: Rendering not updated correctly when using several RenderWindows
Closed, WontfixPublic

Description

This problem can occur if you use two or more RenderWindows and make an interaction in one instance that also modifies the scene in another instance.

The RenderWindow in which the interaction takes place is always correct as VTK forces a re-render of the scene.

The second RenderWindow is not correctly updated unless the interaction somehow triggers a ForceImmediateUpdate. Normally only UpdateRequests are put into the EventLoop. As soon as this Eventloop is processed, the rendering is updated.

The problem is, that User-Input-Events have a higher priority when processing the Eventloop.
For fast interactions this means that many input-events (e.g. mousemove) are handled before the rendering is updated.

This can be seen in the ExtApp when the cross position is moved by clicking into a RenderWindow (in the default layout of StdMultiWidget) and moving the mouse. When the mouse is moved slowly the rendering-event are processed because there are relatively few input-events.
When the interacion is fast (fast mouse movement) there are too many input-events and the rendering is not correctly updated -> the user interacts but does not see any update in the RenderWindows.

This problem could be solved by calling ExecutePendingRequests() on all relevant RenderingManagers (in MITK there should be only one static instance in use). This makes sure that all pending rendering requests are correctly processed before new user-input events are handled.

Event Timeline

I tested a possible fix in commits 350047cd503077c0b02ced2cf1e53fe424274f9b
and b3e777d66dab652d12922aa4ca3d6f54fdfad287 .

This was only a temporary hack to test it. This 'fix' would ruin 3D interaction and requires all possible interactors and listeners that change the scene to call RenderingManager->RequestUpdate() manually as VTK no longer does a forced repaint.

Propagating the events to VTK for 3D-Renderwindows only should fix the 3D interaction. However, all interactor need testing after this change.

I talked to Markus about this. He said that this is actually a Qt feature and very usefull for interaction if one render window is using a very expensive rendering procedure. In that case smooth interaction with other render windows is still possible.

This could be implement as a preference.

New remote branch pushed: bug-9432-correct-rendering-updates

@Mint: What is the status here?

The status of this ticket is basically unchanged. It is still possible to interact with a renderwindow without the rendering being updated.

I had comitted a "fix" for this with commit 350047cd503077c0b02ced2cf1e53fe424274f9b that I've been using until now, so there was no real pressure to get this "fixed". (fixed in "" because we're still not clear about whether this is a bug or a feature!)

We'll switch to the current MITK master soon, so we'll have to think about something that works for all of us.

To sum things up, the two versions currently are:

MITK master:
Input-Events have priority OVER rendering-requests. In case of 'fast' interaction, rendering is not updated at all.

bug-9432-correct-rendering-updates:
Input-Events and rendering-requests have the same priority. Rendering is ALWAYS updated. This makes sure that the scene is up-to-date but can cause lagginess of the interaction when rendering the scene is 'slow'.

A compromise could be to introduce a way to increase the 'relevancy' of the rendering-request with the time. That would prevent the scene to be updated too often as the Input-Events have a higher initial prio. On the other hand, this would ensure the rendering to the updated at some time even if some Input-Events are still pending in the pipeline.

Ok thanks for the update!

Can we implement this as a preference to let the user chose?

Sure, we can use a preference to let the user decide about how the application shall react but it will not fix the problem that rendering-requests and user-inputs rival for compution in the event-loop.

In my opinion, a real solution (like the compromise I proposed or something like that) would be the better solution that has advantages for all users.

I'd like to know what Markus F. has to say about this as he was the one who says it's a feature.

This bug could not be fixed for release 2013-06. Setting target milestone to next release

Markus F.: What do you say to this?

Current release is finished. Reseting target milestone...

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.