Zoom in/out should expand/contract equally on both sides

[Anastasia Baryshnikova]

Right now, when you click on the zoom out button, you add extra rows at the bottom or extra columns on the right. So, whatever you were looking at, moves to the side or to the top, instead of remaining in the middle. Instead, I think the zoom should add equal number of rows/columns on both sides of the current view.

[Robert Leach]

I've got this finished. Been trying to export a runnable jar, but the export is producing a jar that yields this error on the command line:

Error: Could not find or load main class .Users.rleach.PROJECT.TREEVIEW.Eclipse.Builds.tv3_center_zoom.jar

Anyone know how to fix that so I can have you guys test it out?

Rob

[Robert Leach]

My changes are pretty cool too. I rigged it so that if you hold down shift and click the zoom-to-selection button, it will gradually zoom in toward the selection (if a selection exists - otherwise toward the center).

[Christopher Keil]

When you export the JAR, have you made sure to use TreeView3 as the main class? In the past it used to be TreeViewLauncher and sometimes Eclipse mixes these up again when exporting the JAR. It often just sets some random class as the default in the dialog that asks you to select the main class.

[Robert Leach]

I responded via email yesterday because I don't have my bitbucket password memorized. Don't know if it went through. Anyway, yes, I selected "TreeView3 -> LinkedView" as the main class:

Not sure why it's not working, but I'll just move forward by applying my new "zoomToward" method to the option/alt-scroll to zoom toward the cursor and then implement zoomAway as well. Should be pretty sweet when done.

[Robert Leach]

I'm using the same procedure I used back when I was successfully exporting runnable jar files:

To build a runnable JAR file in Eclipse follow these steps: 1. Right-click on the project folder in the Project Explorer. 2. Choose 'Export'. 3. > Java > Runnable JAR file 4. Launch Configuration: Choose the .java file that launches the application, in this case TreeViewLauncher 5. Choose an export destination in which the JAR file should be stored. 6. Select 'Package libraries into generated JAR'. External libraries such as MigLayout which is used for all of the Swing Layout stuff will be packaged here. 7. > Finish

[Robert Leach]

The jar runs for 30 seconds or so with no window and a single app menu called jarRsrcLoader. I can navigate that menu and select the about menu option and that opens an about window. Then the app just quits on its own.

[Christopher Keil]

Works fine for me with the tv3_alpha02 branch. Must be something about Eclipse. Are you compilation settings set to Java 1.7?

Maybe try a refresh/ clean up (both under project explorer -> right-click on project name) as well. But I can definitely build JARs fine.

Check compilation settings by:

Window > Preferences > Java > Compiler

[Robert Leach]

Yes, compilation is set as 1.7. I'll try the refresh.

[Robert Leach]

I tried refresh & cleanup - still same result. If I click on Details after the export, there are these warnings. Do you have the same set of warnings or is anything different? Also, the JRE I'm using is 1.8. Does that matter?

JAR export finished with warnings. See details for additional information.
  Exported with compile warnings: LinkedView/src/Cluster/HierCluster.java
  Exported with compile warnings: LinkedView/src/Cluster/DistanceMatrix.java
  Exported with compile warnings: LinkedView/src/Controllers/DendroController.java
  Exported with compile warnings: LinkedView/src/Views/WelcomeView.java
  Exported with compile warnings: LinkedView/src/edu/stanford/genetics/treeview/WideComboBox.java
  Exported with compile warnings: LinkedView/src/edu/stanford/genetics/treeview/RCSVersion.java
  Exported with compile warnings: LinkedView/src/edu/stanford/genetics/treeview/GeneListMaker.java
  Exported with compile warnings: LinkedView/src/edu/stanford/genetics/treeview/core/LogMessagesPanel.java
  Exported with compile warnings: LinkedView/src/edu/stanford/genetics/treeview/core/AutoComboBox.java
  Exported with compile warnings: LinkedView/src/edu/stanford/genetics/treeview/core/PluginManager.java
  Exported with compile warnings: LinkedView/src/edu/stanford/genetics/treeview/model/TVModel.java
  Exported with compile warnings: LinkedView/src/edu/stanford/genetics/treeview/plugin/dendroview/BitmapColorBarExportPanel.java
  Exported with compile warnings: LinkedView/src/edu/stanford/genetics/treeview/plugin/dendroview/GifExportPanel.java
  Exported with compile warnings: LinkedView/src/edu/stanford/genetics/treeview/plugin/dendroview/ColorPresets.java
  Exported with compile warnings: LinkedView/src/edu/stanford/genetics/treeview/plugin/dendroview/AtrAligner.java
  Exported with compile warnings: LinkedView/src/edu/stanford/genetics/treeview/plugin/dendroview/TreeAnalysisNode.java
  Exported with compile warnings: LinkedView/src/edu/stanford/genetics/treeview/plugin/dendroview/PostscriptColorBarExportPanel.java
  Exported with compile warnings: LinkedView/src/edu/stanford/genetics/treeview/plugin/dendroview/PostscriptExportPanel.java
  Exported with compile warnings: LinkedView/src/edu/stanford/genetics/treeview/plugin/dendroview/GifColorBarExportPanel.java
  Exported with compile warnings: LinkedView/src/edu/stanford/genetics/treeview/plugin/dendroview/BitmapExportPanel.java
  Exported with compile warnings: LinkedView/src/edu/stanford/genetics/treeview/plugin/dendroview/DendroException.java
  Exported with compile warnings: LinkedView/src/edu/stanford/genetics/treeview/plugin/dendroview/AtrAnalysisNode.java
  Exported with compile warnings: LinkedView/src/jargs/gnu/CmdLineParser.java

[Robert Leach]

So when I run the project using the green play button, it runs fine, though I have these errors in the console. Do you get errors like these?:

Directory /Users/rleach/git/treeview3/LinkedView/.//plugins returned null
failing over to /Users/rleach/git/treeview3/LinkedView/plugins/
Directory /Users/rleach/git/treeview3/LinkedView/plugins/ contains no plugins

[Robert Leach]

Here's the error:

Exception in thread "AWT-EventQueue-0" java.lang.IllegalArgumentException: input == null!
    at javax.imageio.ImageIO.read(ImageIO.java:1348)
    at Utilities.GUIFactory.getIconImage(GUIFactory.java:287)
    at Utilities.GUIFactory.createIconBtn(GUIFactory.java:214)
    at edu.stanford.genetics.treeview.plugin.dendroview.DendroView.setupScaleButtons(DendroView.java:484)
    at edu.stanford.genetics.treeview.plugin.dendroview.DendroView.<init>(DendroView.java:220)
    at edu.stanford.genetics.treeview.plugin.dendroview.DendroView.<init>(DendroView.java:166)
    at edu.stanford.genetics.treeview.TreeViewFrame.<init>(TreeViewFrame.java:141)
    at edu.stanford.genetics.treeview.TreeViewFrame.<init>(TreeViewFrame.java:122)
    at edu.stanford.genetics.treeview.app.LinkedViewApp.openNew(LinkedViewApp.java:130)
    at edu.stanford.genetics.treeview.app.LinkedViewApp.<init>(LinkedViewApp.java:76)
    at edu.stanford.genetics.treeview.app.TreeView3$1.run(TreeView3.java:49)
    at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
    at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744)
    at java.awt.EventQueue.access$400(EventQueue.java:97)
    at java.awt.EventQueue$3.run(EventQueue.java:697)
    at java.awt.EventQueue$3.run(EventQueue.java:691)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
    at java.awt.EventQueue.dispatchEvent(EventQueue.java:714)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
    at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
    at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

[Christopher Keil]

These warnings always pop up and don't affect the JAR at all. These are the yellow compiler warnings in Eclipse that should be fixed once we have too much time.

Also try Project > Clean... (that's different than the Source > Clean Up option). This will rebuild the project.

If that doesn't work, try runing it from command line.

And then if still not... can you push your branch to remote? This way I can pull that and see if I can create a JAR. And maybe post a screenshot of the error stacktrace you're getting.

[Christopher Keil]

Oh that looks like a setup issue somehow caused by the new icon file for the zoomToSelected button. It cannot get the file somehow (but you see it when running from Eclipse??) I should definitely also implement a default set back for the buttons in case icons cannot be loaded. ASCII symbols or something.

And yes, the other errors are normal at the moment because it tries to check for plugins that we are no longer including. Java Treeview was plugin based and it checks for these plugins before starting. We only have the DendroView plugin included at the moment.

[Robert Leach]

Yeah, we came to the same conclusion. It's not finding the image for some reason. I do see the icon when I run the project using the green play button.

[Robert Leach]

I added a log print LogBuffer.println("Icon image used: [" + iconFileName + "]."); and get this above the exception now:

Icon image used: [homeIcon].
Icon image used: [full_zoom_in_icon.png].
Icon image used: [full_zoom_out_icon.png].
Icon image used: [fullscreenIcon].
Exception in thread "AWT-EventQueue-0" java.lang.IllegalArgumentException: input == null!
    at javax.imageio.ImageIO.read(ImageIO.java:1348)
    at Utilities.GUIFactory.getIconImage(GUIFactory.java:289)
    at Utilities.GUIFactory.createIconBtn(GUIFactory.java:214)
    at edu.stanford.genetics.treeview.plugin.dendroview.DendroView.setupScaleButtons(DendroView.java:484)
    at edu.stanford.genetics.treeview.plugin.dendroview.DendroView.<init>(DendroView.java:220)
    at edu.stanford.genetics.treeview.plugin.dendroview.DendroView.<init>(DendroView.java:166)
    at edu.stanford.genetics.treeview.TreeViewFrame.<init>(TreeViewFrame.java:141)
    at edu.stanford.genetics.treeview.TreeViewFrame.<init>(TreeViewFrame.java:122)
    at edu.stanford.genetics.treeview.app.LinkedViewApp.openNew(LinkedViewApp.java:130)
    at edu.stanford.genetics.treeview.app.LinkedViewApp.<init>(LinkedViewApp.java:76)
    at edu.stanford.genetics.treeview.app.TreeView3$1.run(TreeView3.java:49)
    at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
    at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744)
    at java.awt.EventQueue.access$400(EventQueue.java:97)
    at java.awt.EventQueue$3.run(EventQueue.java:697)
    at java.awt.EventQueue$3.run(EventQueue.java:691)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
    at java.awt.EventQueue.dispatchEvent(EventQueue.java:714)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
    at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
    at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

It's that last one. Shouldn't it have a .png extension?

Rob

[Christopher Keil]

No. That should be refactored but way back we had "themes" implemented in treeview so there was a light and dark version of each PNG. The ones with _dark extension in their names are parsed differently I think...

[Robert Leach]

I couldn't figure out how to get past the error, so I'm just going to move on. I want to implement zooming toward and away from the cursor when option-scroll occurs. In the meantime, here's a screen recording of the new zoom functionality. Note that zooming toward a selection only occurs if there is a selection and the shift key is held when clicking the zoom selection button.

https://bitbucket.org/TreeView3Dev/treeview3/downloads/new_zoom_functionality.mov

Note, this doesn't demonstrate some of the rarer cases, such as zooming toward an off-screen selection. The first thing that happens when you do that is the view shifts to bring the selection into full view. If the current zoom level is zoomed into an area smaller than the selection, the result is essentially what would happen if the zoom-to-selection button was pressed without the shift held.

[Christopher Keil]

Looks really good, great job! Did you also bind the axis buttons to the add/ remove for the new buttons yet?

[Robert Leach]

I assume by axis buttons, you mean the buttons flanking the scroll bars? No, I intentionally did not change those because I thought that the point of having those there was to add/remove rows/cols on each side of the heatmap individually - thereby retaining the functionality we've had up to now and less complicate the navigation button group. I have left the axis buttons alone specifically so that buttons could be added on the left and top of the scroll bars that add/remove columns/rows from the other side of the matrix. If they did the same thing as the zoom buttons in the group of navigation buttons, there'd be no reason to have them there.

What I have done however is implement zooming toward and away from the position of the cursor (when the option key is held during scrolling). I've got it working fairly well, but am currently seeing if I can make it any smoother by both detecting relative positions inside a cell and by tweaking the number of rows/cols shifted on each side.

[Robert Leach]

Here's a question. So imagine that you hover over a square you want to zoom toward. You zoom in partly or most of the way - then you become interested in another square and decide to zoom out a little with the cursor over the new square. Having the cursor remain over the same square as you zoom out keeps the user oriented, i.e. they don't get lost. However, at some point, zooming out any more will cause the square you're over to shift out from under the cursor (because you've hit the edge of the data). The user might find this disorienting and get lost. Do you think in this case, it would be better to stop the zoom-out at the point at which the square their hovering over would slip out from under the cursor? I'll do a screen recording here so you see what I mean:

https://bitbucket.org/TreeView3Dev/treeview3/downloads/zoomin-move-zoomout-shift.mov

BTW, I think that I have smoothed the zooming as much as I can using relative positions, though I might be able to smooth it more using slight zoom level tweaks.

[Christopher Keil]

Yea the zoom-to-selected looks great from what I can tell in the video. I know the buttons next to the scrollbars shouldn't do the same as zooming. I thought for the zoom-to-selected maybe you already implemented methods to remove rows/ cols from the other sides. Then those could have been bound to the buttons.

As for the disorientation, yea that was a big gripe when I tried to implement the zoom-to-cursor issue over Christmas. It's unavoidable because the matrix is currently forced to fill the entire viewport that has been granted to it. The currently disabled methods for setting the viewport to "axis-proportional" or "equal" just changed the size of the viewport depending on the number of tiles per axis, thereby changing the amount of availablePixels in MapContainer to which the tile sides will adapt.

We could potentially use this so the zooming would be smoother by keeping the relative scales (or tile side proportions) constant. Changing the viewport size would allow us to display more/ less tiles while keeping the same tile scale for each MapContainer (--> numTiles/ availablePixels in MapContainer). It's a possibility although I think that would be weird since we are shrinking or growing the matrix viewport. Potentially even more irritating then jumping single tiles.

This is the only other solution to the "jumping tile" problem when zooming aside from locking the zoom when one of the four matrix sides has reached the first or last row/ col to display (when you cannot add or remove more rows/ cols on one side). If we would stop the zoom though we are making assumptions about what the user wants to do. They might just randomly have their cursor there and zoom out and expect the matrix to fully zoom out.

It's again an issue related to the inability to display partial tiles. Implementing all this with a normal JScrollPane would be a piece of cake.... but then the Dendrograms and labels go crazy and all the painting/ mapping code has to be adapted. I might play around with this when I have some free time. If I get something to work maybe it would be worth taking some time to implement that.

[Robert Leach]

Well, that's not the only way to handle it. I implemented a pretty slick smoothed-zoom function that tweaks the amount of zoom to match the pixel ratio of the cursor position. The only problem is that I can't keep the axes proportional. It looks really smooth, but, depending on the location of the cursor, sometimes the squares either end up distorting horizontally or vertically. I'm tweaking a few parameters to see if I can find a good balance.

[Robert Leach]

Here's the closest I've gotten with the zoom trickery. I implemented the smoothing on the zoom-in, but not on the zoom-out, so you can see the bumpiness of the zoom-out compared to the smooth zooming of the zoom-in. But you can also see how the proportions get more and more distorted as you go.

https://bitbucket.org/TreeView3Dev/treeview3/downloads/smooth_zoom_trick.mov

If the mapcontainer object had both axes recorded in 1 object, I could likely smooth proportionally using my zoom level tweak trick and a bit more math.

I've got to set this aside for now. I need to switch gears briefly to get something done for another project by tonight.

[Robert Leach]

So I've been working on this today some more. I developed what I would call a proportion correction threshold. It corrects the shapes of the squares when they diverge too much from their starting shapes while zooming. So basically, it balances smoothness of zooming with degree of dot distortion. The higher the threshold, the smoother the zoom, but also the more distorted the dots are allowed to get before making a proportional correction. The lower the threshold, the more frequently the proportion correction kicks in because it tolerates less distortion in the x/y ratio (and the more bumpy the zoom). If you set it to 1, you get as smooth a scroll as is reasonably possible (but sometimes really distorted "squares"). And BTW, sometimes in certain spots on the matrix, even that can be a little bumpy.

I'm not sure I think it's ready for primetime. I can't tell which behavior is less disorienting: no smoothing at all or some degree of smoothing with occasional proportion correction. Maybe it would just be best to only zoom toward the center square whenever someone uses the mouse to zoom. What do you think Chris? Here's a screen recording of an example of smoothing with 0.5 proportion correction. Note, I've only implemented this for zoom in, so you'll see no smoothing whatsoever on zoom out:

https://bitbucket.org/TreeView3Dev/treeview3/downloads/smooth_zooming_with_0.5proportion_correction.mov

I feel like this is about the best I can do with the fact you can only display whole cells.

What do you think Anastasia?

[Anastasia Baryshnikova]

Both options seem to be reasonable in the movie, but I'd have to play with it live to have a more precise feeling. Is there a Jar file I can play with?

[Christopher Keil]

@hepcat72 had some problems creating the JAR. Not sure if he still does, but if so try pushing your working branch to remote, Rob. This way I can download it and try creating a JAR from my end.

[Anastasia Baryshnikova]

Yeah, i am at a meeting this week, will be back on monday. Let's chat then! Btw, i saw some of our alpha testers at this meeting, more feedback about Treeview is on its way.

A.

[Robert Leach]

Hey Chris, so this code is moving forward. I have tweaked it a bit more and have it working pretty well. I know that you were trying to move the zoom-specific code out of GlobalView, which is why I'm seeking your feedback on this effort.

I have to track the "aspect ratio" of the dots being viewed when zooming occurs and the best place to store that seems to be in the GlobalView class (because MapContainer objects only know about a single dimension at a time). Basically, I have some code associated with monitoring the current aspect ratio, as it morphs from the smoothing code in MapContainer (because it ends up zooming at different levels in each dimension). The monitoring compares the current aspect ratio with the starting aspect ratio and makes corrections during the zooming by manipulating the percentage of zoom. Ideally, I would like that code to live in MapContainer, but since it involves more than a single dimension, that doesn't make sense, so my plan is to encapsulate it in a function in GlobalView. I'm open to having it live elsewhere since it is zoom-related, so I just thought I would mention it before I finish up and push this out - or it could be a todo item after I write it...

There are a few things I have yet to do however. I have to update the stored aspect ratio when the user explicitly changes it (e.g. using the +/- buttons next to the scroll bar or using the zoom-to-selection and home buttons). I have to add my smoothing code to the zoom-out functionality. There's also some general code clean-up, including encapsulating the code that's currently in the mouseWheelMoved function. I want to change the cursor appearance when a modifier key is held, but I may do that in a subsequent commit.

There are a few parameters that are involved, but conceptually, there are really only 2 things going on: 1. Selecting a zoomVal that results in the hovered-over dot expanding smoothly underneath the cursor (using a loop over a range of numbers of "rows" to add/remove) and 2. monitoring dot shapes to make corrections when the two axes zooming at differing levels get out of a target aspect ratio range. Right now, the smoothing happens in MapContainer and the correcting happens in GlobalView.

To fine-tune the smoothing settings, I have a few different variables with hard-coded values (these occur in different places in the code - I just grouped them here):

GlobalView
double targetZoomFrac = 0.05; //The default incremental percentage of each zoom (adjusted when a threshold below is crossed)
double aspectRatio = -1; //A data member used to store the starting aspect ratio. As zooming occurs, the current ratio gets off and the stored data member is used to measure distortion and make corrections. -1 = unset.
double numXCellsShouldHave = aspectRatio * (double) numYCells; //This is calculated on the fly. The number of X dots that should exist given the number of Y dots and the stored aspectRatio.  This is only used to decide whether to add to the targetZoomFrac for the X or Y axis.

MapContainer
adjustWindow = 10; //The range in which to look for a zoomVal that will provide a smoother zoom appearance.  Changes to 3 when smallThresh is crossed
smallThresh = 15; //When the number of dots currently visible is at or below this value, it switches adjustWindow to 3.
minDiffThresh = 0.005; //Stop looking through the adjustWindow range when we have found a zoom value that allows the target dot position stay in place within a fraction close to 0.

Do you have any thoughts on this?

Rob

[Christopher Keil]

For now it's fine to add it to the code base like you already did. I made some pretty big changes to GlobalView in response to adding a global overview panel (a lot of alpha01 criticism was about that). That is implemented and working fairly well.

GlobalView was renamed and split into 3 classes:

• MatrixView -> contains basic matrix code that is usable for the interactive main matrix as well as the global overview matrix.
• InteractiveMatrixView -> former GlobalView but only contains the interactive or specific code now (drawing, MouseListener, selection rectangle etc.)
• GlobalMatrixView -> The non-interactive overview panel.

When I merge that branch I will simply have to work my way through the merge conflicts (which are always 2 presented options). It would be great if you could specifically mark your code so I can easily recognize and choose it. But that should not even be necessary.

Once the whole stuff functions we can go ahead and debug, declutter, rearrange, clean etc. It would have been easier to plan and structure things from the ground up but it is what it is now.

[Christopher Keil]

Also, would you be able to do a quick test run of that global overview stuff? I uploaded a JAR. It's still a bit clunky I suppose but I hope I can merge it later tonight or once you merged your code.

[Robert Leach]

I'll take a look

[Robert Leach]

Initial test looks good, though there are a couple things:

1. Resizing the window larger causes the margins of the global view to fill with white:
2. Initial app launch is noticeably slower.

Also, I know I haven't provided any thoughts on the global view up to this point, so it's somewhat after the fact, but what would you think about these possibilities:

Only show the overview/globalview when zoomed in. What happens if there aren't enough pixels in that corner for all the data, do you average the colors? Have you tested it with 6kx6k matrix? Could the overview pop-out of the main window or be dismissed all together?

Rob

[Christopher Keil]

At the moment it's permanent. The issue with the pixels is rather important because it affects both matrices. A 6k x 6k matrix has 36,000,000 data points (= pixels). The most modern 5k monitors can display less than half of that for the entire monitor (e.g. Apple's 5k retina display comes in at 14.7 million).

It's a waste and doesn't make sense to draw all the pixels but that's what currently happens. I am not sure how Java is handling that but it would make sense to lower the resolution. We need to discuss ways of doing that. This would also significantly improve performance. The absolute maximum of what we should draw is likely 10 million pixels (as we won't ever be full screen on a 5k monitor with just the matrix). That leaves 26 million pixels for a 6k x 6k matrix unaccounted for. Those savings on calculating colors could save us a lot of repainting time which would make any repainting (color change etc.) far more responsive.

We cannot display the data anyways. We need to find some form of useful approximation that doesn't disturb the expression pattern of the overall matrix.

Btw I did not notice any reduced speed when launching the app. The white space happens because the MapContainers for the overview matrix aren't updated with new availablePixels so I'll fix that up.

[Robert Leach]

Huh, you're right. I've tested a 6kx6k before, and it loads without complaint. What is happening? Is it only displaying a subset of the data when I do that? If 6kx6k is a goal of ours, then we either need to average pixels in some way as you suggest that preserves important trends OR we need the home view to be a certain amount zoomed in somewhere so that 1 pixel = 1 data point at a minimum. When I load my 6kx6k file, there's definitely a lot of data displayed and the image is mostly black. The overview is solid black, though I can see some red/green stippling in the main matrix. My large file is available on the downloads page, but it's just a duplicated rows/cols of another file.

As to the launch speed, the jar you sent takes over 20 seconds to display the main window. It's snappy after that.

[Robert Leach]

BTW, the highlight in the overview gets too small to see in the overview for a 6kx6k matrix.

[Christopher Keil]

When I use the code run from Eclipse there's no change in loading time at all... weird. In general cleaning up the Matrix/ MapContainer/ DendroController code should be a priority because so much code is run multiple times, especially resetting MapContainers (several changes trigger that)... the drawing and MapContainer calculations are such a huge mess. Everything could be way snappier and cleaner.

[Christopher Keil]

The issues you mentioned have been addressed, done some quick testing:

• There's a minimum size for the viewport rectangle
• The overview matrix resizes well with the window

Put up another JAR if anyone feels like taking a look.

[Robert Leach]

Likewise, I'm getting close on this issue. Keeping the aspect ratio isn't working terribly well on zoom out. It's working on zoom in very well. I think I know why though.

[Christopher Keil]

Ok. If you feel confident, then just merge. Until then I'll do some more tweaking and also finally get back on the color stuff... once your code is live I will merge and resolve the inevitable merge conflicts.

[Robert Leach]

This is done, though could be improved as indicated in the commit message. Basically, the changes have to do with using a trick to smoothly zoom when only whole squares can be displayed. I also implemented a gradual zoom to selection when the button is clicked while holding the option/alt key. Oh yeah, I also meant to implement a change of the cursor icon that I did not do yet to indicate the function. Changing the button icons would be a good idea too.

[Robert Leach]

Removing milestone: Alpha02 Release (automated comment)

[Robert Leach]

Merged to master.