Menu

#102 Configurable rendering of virtual scaffolds

next release
closed
BR 263, BR 268
5
2017-08-28
2016-11-23
Nils Kriege
No

An option should be added, which allows to choose between two rendering strategies:

  • virtual scaffolds are rendered just as other scaffolds or
  • virtual scaffolds are drawn in grey (currently implemented).

Discussion

<< < 1 2 3 4 > >> (Page 2 of 4)
  • Philipp Mewes

    Philipp Mewes - 2017-01-26
    • status: in-progress --> needs-review
     
  • Till Schäfer

    Till Schäfer - 2017-01-26
    • status: needs-review --> re-opened
     
  • Till Schäfer

    Till Schäfer - 2017-01-26

    There is one small thing remaining:
    When restoring an existing session that was created before the variable markVirtualScaffolds was added to the ScaffoldTreeViewState, the state defaults to false / "do not grey out virtual scaffolds". This may somewhat related to the sessions loading mechanism that is using default values for undefined (i.e. added) variables. Is there any easy way to change the default (of this single variable) for outdated sessions, too?

    (If there is no easy workaround or a workaround is hacky / messes up the code structure, we may just move this feature to the next minor release (i.e. 2.7) and keep it the way it is.)

     
  • Philipp Mewes

    Philipp Mewes - 2017-01-27
    • status: re-opened --> in-progress
     
  • Philipp Mewes

    Philipp Mewes - 2017-01-31

    After analysing the code, i still not know the exact line, which causes the problem, but i'm sure that it is located inside the external framework, so we are not able to fix it that way.
    I invented a small modification of the view-state as a workaround: Instead of using a boolean-variable which is set to false, if it is not defined in the stored state, it now uses an int-variable, with default-value of 0. So, if markVirtualScaffolds is set to 0, the getter can return the boolean-value, that is meant to be the default.
    [94dc8a] contains the modifications.

     

    Related

    Commit: [94dc8a]

  • Philipp Mewes

    Philipp Mewes - 2017-01-31
    • status: in-progress --> needs-review
     
  • Till Schäfer

    Till Schäfer - 2017-02-17
    • status: needs-review --> re-opened
    • Depends On: --> BR 263
     
  • Till Schäfer

    Till Schäfer - 2017-02-17

    The solution works as expected. However, it would be nice to solve the problem of default values in a more general manner. Sadly, there is not an easy solution. Thus, I have created a seperate bug #263. Let's elaborate if the generall approach is possible, otherewise i will merge the current state back to master.

     

    Last edit: Till Schäfer 2017-02-17
  • Till Schäfer

    Till Schäfer - 2017-03-17

    Another bug: currently the cloud view option does not have any effect.

     
  • Philipp Mewes

    Philipp Mewes - 2017-03-20
    • status: re-opened --> in-progress
     
  • Philipp Mewes

    Philipp Mewes - 2017-03-20

    Can't reproduce this. Seems to work here (see screenshots). Did i missunderstood something?

     
  • Lina Humbeck

    Lina Humbeck - 2017-03-20

    It is somehow strange. The Minimap changes but only if the layout is updated, e.g., by zooming. I attached two screenshots from us. We would like to have all the structures black.

     
  • Philipp Mewes

    Philipp Mewes - 2017-03-21

    Oh yes, i see. The feature was not implemented for closer zoom-levels. [99ad08] fixes this.
    But as You mentioned, there are still some issues with the minimap. I will investigate this too.

     

    Related

    Commit: [99ad08]

  • Philipp Mewes

    Philipp Mewes - 2017-03-22

    The minimap is updated now, too ([8f3979]).

     

    Related

    Commit: [8f3979]

  • Philipp Mewes

    Philipp Mewes - 2017-03-23
    • status: in-progress --> needs-review
     
  • Nils Kriege

    Nils Kriege - 2017-03-23
    • status: needs-review --> open
     
  • Nils Kriege

    Nils Kriege - 2017-03-23

    Updates should be triggered by calling setPaintInvalid(true) instead of repaint().

     
    • Philipp Mewes

      Philipp Mewes - 2017-03-24

      The MiniMap is not a child of PNode and therefore does not offer the method setPaintInvalid(). Is there a similiar function to call?

       
      • Nils Kriege

        Nils Kriege - 2017-03-24

        Whenever an attribute of a PNode is changed that affects its rendering, the method setPaintInvalid(true) should be called. Therefore, this call should be added to the method setMarkVirtualScaffold() you have introduced. When this call has been added, you should try to remove all repaint()-calls you have added, since they should be unnecessary. The piccolo framework will trigger all necessary repaints, see Pattern 15/16: http://piccolo2d.org/learn/patterns.html

         
        • Philipp Mewes

          Philipp Mewes - 2017-03-27

          Since MiniMap is derived from PCanvas it does not have any member setPaintInvalid().
          I tried it with

          minimap.getRoot().setPaintInvalid(true);
          minimap.getRoot().validateFullPaint();
          

          but it does not work. Same for CloudCanvas.

           
          • Nils Kriege

            Nils Kriege - 2017-03-27

            The call should be added to the method setMarkVirtualScaffold() of CloudNode which extends PNode.

             
  • Till Schäfer

    Till Schäfer - 2017-03-23
    • status: open --> re-opened
     
  • Philipp Mewes

    Philipp Mewes - 2017-03-27
    • status: re-opened --> in-progress
     
  • Philipp Mewes

    Philipp Mewes - 2017-03-28

    Adding the call to CloudNode works. Only nodes that can be greyed out are marked for repaint, if setMarkVirtualScaffold() is called, which might improve the performance. The minimap is now updated automatically and needs not to be updated explicitly. See [668acc] for details.

     

    Related

    Commit: [668acc]

    • Nils Kriege

      Nils Kriege - 2017-03-28

      Thanks for the update. I checked the code and noticed that I have been wrong: It is not setPaintInvalid(true), but invalidatePaint() which should be called. I have changed this with commit [43e231]. The method invalidatePaint() automatically propagates to the ancestors in the scene graph, which allows further simplification of the code. Could you please check if the updates still work for you and report back?

       

      Related

      Commit: [43e231]

<< < 1 2 3 4 > >> (Page 2 of 4)

Log in to post a comment.