You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the depth map assumes that graphs always have child areas. This results in features using the depth map such as smart zoom and the planned proxy-view not working for graphs which do not use child areas. In those cases calling getContainingRegion always returns undefined.
The big issue here is conflating rendering details with the underlying graph structure. kChildAreas are rendering elements, however they also fulfill some structural role, which is probably why they were misused here in the first place. Fundamentally the question is: should child areas be only a rendering element or should they be some structural element. In that case would it be reasonable to demand that any hierarchical graph has to use child areas?
If the responsibility is shifted into the diagram syntheses, the rendering doesn't need to specially handle the special case when no child areas are explicitly defined. On the synthesis side the solution would be to assign the child area (if none is explicitly defined) to the "main" rendering of the node. This should correspond to the way it currently works anyway, while improving support for rendering features that utilise the structural information provided by child areas.
The text was updated successfully, but these errors were encountered:
Currently the depth map assumes that graphs always have child areas. This results in features using the depth map such as smart zoom and the planned proxy-view not working for graphs which do not use child areas. In those cases calling
getContainingRegion
always returns undefined.The big issue here is conflating rendering details with the underlying graph structure. kChildAreas are rendering elements, however they also fulfill some structural role, which is probably why they were misused here in the first place. Fundamentally the question is: should child areas be only a rendering element or should they be some structural element. In that case would it be reasonable to demand that any hierarchical graph has to use child areas?
If the responsibility is shifted into the diagram syntheses, the rendering doesn't need to specially handle the special case when no child areas are explicitly defined. On the synthesis side the solution would be to assign the child area (if none is explicitly defined) to the "main" rendering of the node. This should correspond to the way it currently works anyway, while improving support for rendering features that utilise the structural information provided by child areas.
The text was updated successfully, but these errors were encountered: