Row highlight imprecise when "show trees" is active
Issue #92
closed
I discovered this while testing the search feature, but it happens when you just click around. I've attached a screen-capture. The yellow highlight is offset on a lot of the rows when "show trees" is active. Some rows are OK.
When "show trees" is not active, all highlights appear to be accurate.
Comments (21)
-
reporter
-
reporter
-
assigned issue to
Robert Leach
-
assigned issue to
-
reporter
- marked as major
-
repo owner
Check if this occurs together with some white spaces on the edges. This means that the JPanel (GlobalView2 I think) is not being set with the accurate width/ height parameters. It's a bug from recalculating the size of all components in DendroView when the tree-boolean is true. Clicking the home button usually fixes this.
-
reporter
There is some white space at the bottom when that happens. In fact, resizing the window no longer reflects the change I made to make the number of visible spots the same and just update the zoom.
-
reporter
This issue may be related to the re-emergence of the window-resize issue, so I'm working on that. It appears that the resize works for a little bit as you resize the window, but the reZoomVisible function stops updating after you drag so far. If you drag back out, it starts working again once you get to some arbitrary size.
-
reporter
You know, I tried checking out the version from my commit when I'd fixed the resize issue and it still happens there... I know it wasn't happening when I fixed it. I guess I don't know if my checkout worked or not.
-
reporter
Yeah, my checkout definitely didn't do what I expected because I just tried a jar file I'd saved from the fix and it worked there. How do I check out an older version? I had tried selecting checkout from the version I wanted in the history tab...
-
reporter
I tried checking out an older version on the command line too (git checkout 5319dbd0f89a55dc11222e99a52c76af1528e2f6), but when I opened up eclipse, it wouldn't run it - said there were errors. I can check master back out and it runs fine. It seems that simply checking out a previous version is not enough... sigh I guess I'll have to re-fix this the hard way.
-
repo owner
I tried testing this again and it seems to work fine starting from a certain zoom level at each axis. If I increase the scale a bunch of times it suddenly resizes fine with the window and the focus/ zoom will not be changed.
But when zooming out there is a scale between 'Home' and zooming in on either axis a few times where this doesn't work. The matrix panel resizes but the pixel scale/ zoom does not.
I think I had to click the zoom in button about 10-12 times before it works. So if I zoom in 12 times on the x-axis, but not the y-axis, the x-axis will resize fine but the y-axis will not.
-
reporter
OK, I think I fixed the reZoomVisible issue and am trying to address the white margin issue that causes the highlight to be off (though I can't be certain that's the only reason the highlight is off)... I suspect that componentResized is simply not getting called frequently enough - or is at least not getting called when the last row/col of pixels is added or removed. If I resize the window really fast, it's usually off by quite a bit. So I am looking to see if I can do a final re-zoom when the mouse button is released (from doing a window resize). At the very least, I could do a re-zoom every time a selection is made (or I could somehow update the coordinate system that selecting things uses in the componentResized method...
-
reporter
The setScale function was setting the minimum scale, so if you resized the window and then hit the home button, it was setting that as the minimum scale. So later when you resize the window - if you went smaller, the rezoom wouldn't work. I'd thought this was working before, but maybe this was a use-case I missed. Anyway, that part is fixed in my uncommitted copy.
-
reporter
This might provide a solution:
Not sure I like the timer solution, but the mouse released trick looks nifty. I think I could let componentResized do it's thing and also set a flag that the mouse listener checks whenever the mouse button is released.
-
repo owner
Ok I think you can try it out and see how it works. Btw I solved the issue with the clustered matrix not appearing right away while implementing proper threading for loading the data. Should be up and running soon.
-
reporter
Well, I have determined that reZoomVisible is executing at the final window dimensions after a drag, so it's not necessarily reZoomVisible that needs to be called. I think it just needs a repaint. I suspect that perhaps something somewhere is picking and choosing the repaint events to do & which to skip. My debug prints show the same scale calculations as what you get when you click the home-button while looking at an image that is not fully updated after the resize.
-
reporter
Hmmm... the repaint seems to keep up if I'm zoomed in on everything but the first & last row/col. And it looks like my fix for the scale thing isn't quite there yet - it's letting me zoom out past the size of the data matrix. I'll have to figure out a way to set the min.
-
reporter
Even though it appears to keep up, it actually makes mistakes - changing the zoom level by a column or a row, which sticks through other manipulations. I think that this may also cause the highlight to be off and possibly other issues.
I'm beginning to think that since the debug prints show that the last re-room triggered by componentResized has the same scales as when you hit the home button after the resize (which fixes the image) that updatePixels is running before the re-zoom calculations are done...
Ha! I fixed it. My reZoomVisible function just needed to make a call to global{X,Y}map.notifyObservers()!
I think this should fix the highlight being off. I'll check that.
-
reporter
OK, so I just confirmed that some change made since my last commit/merge has caused a problem with the window resize fix. I had isolated the things I needed to do to make the problem happen and then I went back to one of my old jar file exports and performed those same tasks and the problem did not occur. I will try and see again if I can isolate which commit/merge introduced the bug so that I can focus on those changes that were made.
I think that once I figure this out, I will be able to apply my fix to this current issue and it should work.
Here's a better description of what happens: When you resize the window smaller, the image no longer shrinks. Rather, the heatmap floats off the edges. When I tried to fix that, it seemed to work, but then when you hit the zoom selection button after the resize, it would zoom in past the selection in the horizontal orientation.
Perhaps I'll create another issue for this problem and address it separately from my code which fixes the selection offset from the underlying image.
-
reporter
- changed status to resolved
Just had to have a notifyObservers call in the componentResized method.
-
Tested. Works great.
-
repo owner
- changed status to closed
- Log in to comment
Here's a zoom-in of an area in the above image. You can see in this instance, it's hard to tell which row is actually selected. For that reason, I'm bumping this up to major.