Page MenuHomePhabricator

Improve reinit behavior
Open, NormalPublic

Description

Reinit and global reinit currently also reset the views/crosshair and the time step. In most use cases this is rather annoying, for example when creating a segmentation and the current time step and cross hair position is reset. However, one may want to reset everything to see each and every data node in the scene. I propose to do two things:

  1. Do not reset anything unnecessary when doing a reinit
    • Keep cross hair position if it fits, adapt it to the new scene bounds to stay virtually at the same position, and only reset it if both soft approaches do not work
    • Basically same for time step
    • Do not reset the 3d camera angle/orientation
  2. Introduce a true "Reset scene/view" operation which basically equals the current reinit operations.

Revisions and Commits

Event Timeline

kalali edited subscribers, added: kleina; removed: thomass.EditedJun 25 2021, 4:18 PM

Just for testing purposes: I created an additional Enum value to mitk::RenderingManager::RequestType, called NO_UPDATE. I'm using this new value inside QmitkSegmentationView::CreateNewSegmentation, for the call mitk::RenderingManager::GetInstance()->InitializeViews(referenceImage->GetTimeGeometry(), mitk::RenderingManager::NO_UPDATE, true);.

The result is that the render view is not being reset when a new segmentation node is created (using the "New..."-Button). What happens inside RenderingManager::InitializeViews:

if (((type == REQUEST_UPDATE_ALL) || ((type == REQUEST_UPDATE_2DWINDOWS) && (id == 1)) ||
     ((type == REQUEST_UPDATE_3DWINDOWS) && (id == 2))))
{
  this->InternalViewInitialization(baseRenderer, timeGeometry, boundingBoxInitialized, id);
}

lead to InternalViewInitialization NOT being called (since the new type mitk::RenderingManager::NO_UPDATE does not fulfill the if-condition).

So it seems as if there is already the possibility to separate the geometry resetting and the render view / crosshair resetting. Need to investigate to check different cases and find possible side-effects.

For a more thorough investigation of possible side-effects I will list the occurrences of similar code and see if the mentioned solution could be applied there.
I already started doing that some time ago in T26496: [mxn multi widget] Re-initializations reset all render windows and will continue there:

In T26496, @kalali wrote:

I propose to first gather different actions which lead to an update request.

kalali added a revision: Restricted Differential Revision.Mon, Jul 5, 6:05 PM

My conclusion / suggestion so far:

  1. RenderingManager::RequestUpdate*-functions add render windows to a list of render windows to be re-rendered, where re-rendering means updating the graphics / pixel (OpenGL)
  2. RendereringManager::InitializeView*-functions (changed to RenderWindowManager::InitializeView* in D517) update the Time- / Slice-Navigation controller and the camera controller to a specific view ("field of view").

RequestUpdate*-functions should only be called if the graphics / pixel have been changed.
InitializeView*-functions should probably not be called automatically in most cases, as they reset the user generated "field of view".

kalali raised the priority of this task from Wishlist to Normal.Wed, Jul 7, 10:29 AM
kalali edited projects, added MITK (v2021.10); removed MITK.
kalali moved this task from Backlog to Cycle on the MITK (v2021.10) board.