Single Axis Scaling should not scale the 'view' transform

[tomnelson]

Normal scaling affects the layout positions only when scale is > 1.0 and affects the view (telescope effect) when scale is < 1.0. When single axis scaling is enabled (CTRL or ALT button with mouse wheel) the view will do the same and squish the vertices. Perhaps single axis scaling should apply only to the layout transform.

[fmagin]

Eager to try this, but I am currently confused about:

Snapshots of JUNGRAPHT-VISUALIZATION built from the master branch are available through Maven using version 1.0-SNAPSHOT

but when changing the Ghidra GraphServices gradle file to:

repositories {
    mavenCentral()
}

dependencies {
    compile project(":Base")

//  compile "com.github.tomnelson:jungrapht-visualization:1.0-RC9"
    compile "com.github.tomnelson:jungrapht-visualization:1.0-SNAPSHOT"
...

the Ghidra import fails with

Could not resolve all files for configuration ':GraphServices:runtime'.
> Could not find com.github.tomnelson:jungrapht-visualization:1.0-SNAPSHOT.
  Searched in the following locations:
    - file:/home/fmagin/.m2/repository/com/github/tomnelson/jungrapht-visualization/1.0-SNAPSHOT/maven-metadata.xml
    - file:/home/fmagin/.m2/repository/com/github/tomnelson/jungrapht-visualization/1.0-SNAPSHOT/jungrapht-visualization-1.0-SNAPSHOT.pom
    - https://repo.maven.apache.org/maven2/com/github/tomnelson/jungrapht-visualization/1.0-SNAPSHOT/maven-metadata.xml
    - https://repo.maven.apache.org/maven2/com/github/tomnelson/jungrapht-visualization/1.0-SNAPSHOT/jungrapht-visualization-1.0-SNAPSHOT.pom
    - https://jcenter.bintray.com/com/github/tomnelson/jungrapht-visualization/1.0-SNAPSHOT/maven-metadata.xml
    - https://jcenter.bintray.com/com/github/tomnelson/jungrapht-visualization/1.0-SNAPSHOT/jungrapht-visualization-1.0-SNAPSHOT.pom
    - file:/home/fmagin/GhidraDevel/ghidra/flatRepo/jungrapht-visualization-1.0-SNAPSHOT.jar
    - file:/home/fmagin/GhidraDevel/ghidra/flatRepo/jungrapht-visualization.jar
  Required by:
      project :GraphServices

am I misunderstanding the instructions in the README? I'll just checkout the repo and build it myself now, but I am wondering if this is a bug and not intended or if I am misunderstanding how the Maven repositories and Gradle interact

[fmagin]

after compiling myself and testing it for a few minutes: The initial issue is definitely solved and this is significantly better! One quirk that comes up is that the edges that aren't straight will, after a certain zoom level, be transformed in a way that the angle between an edge and the vertical axis isn't acute anymore:

This isn't that bad, but potentially something that can easily be fixed by also scaling the point between the two edges to two vertices also gets scaled.

[tomnelson]

Glad you worked out a solution. I also saw that the articulated edges (min cross layouts) lose their way when scaling in separate axes. I will think about a solution to that. As far as the spacing goes, for the hierarchical layouts, the algorithm that computes overall space considers the average vertex size, then makes them 2x apart. That may work better for dense graphs than for the smaller ones.

[fmagin]

And if I play around with other extreme and use this on my other 4K monitor that is rotated 90° the nodes start to overlap vertically. But during that something even more interesting came up:

Graph generated initially:

Graph after combining normal zooming(MWheel only), ALT and CTRL scrolling to zoom:

the graph layout is basically the same, so what I effectively did was just increasing the size of the nodes dynamically. I am wondering if this effect could be achieved directly somehow and then automatically applied to a degree that suits the screen resolution

[tomnelson]

This is what I do for testing: repositories { mavenLocal() maven { url "https://oss.sonatype.org/content/repositories/snapshots" } mavenCentral() jcenter() }

Unfortunately, gradle does not work well with maven snapshots and the snapshot repo. I had to hard-code the repo url

[fmagin]

I think this might be related so I am posting here instead of opening a new issue:

It seems like the area in which the hovertext for the vertex is displayed does not scale with the size of vertex. If I render a graph and then scale the axis with ALT and CTRL plus MWHEEL the area I have to hover over to get the hovertext is the same size as originally (so only a few pixels high in my case)

[tomnelson]

I'll look into this. The area for the tooltip text activation should be the same as the area that you can CRTL-click to select the vertex. I don't see this in any of this project's samples, but I will write something to expose the problem. Thanks for your support!

[fmagin]

That seems right, CTRL clicking for selecting didn't really work either, so this is the same underlying problem

[tomnelson]

There is a spatial data structure (R-Tree) that optimizes vertex selection. It's a tree of rectangles representing vertex shapes that can be searched in log-n time instead of n time. The issue appears to be that by modifying one axis and not the other, the squashed shapes in the R-Tree are not correctly representing the un-squashed shapes we see, so the vertex selection is rejected by the R-Tree before it actually tests the shape (it finds no candidate 'leafs' in the RTree because the shapes are wrong). Turning off the R-Tree solves this, but is not a good approach. I have a sample program (SpatialLensDemoWithThreeStarVertices) that shows the problem and that I can use to test a solution.

If you'd like to try this, you can remove the RTree with a simple property change in the jungrapht.properties file: change this: jungrapht.vertexSpatialSupport=RTREE to this: jungrapht.vertexSpatialSupport=NONE I don't think you will see any performance difference except for very large graphs.

[tomnelson]

I pushed a change to the master branch (1.1-SNAPSHOT). I believe that it fixes this issue. If you like, please make your Ghidra pull in 1.1-SNAPSHOT to test.

[fmagin]

Hovertext works as expected now :+1: