Persistent Frame in Profile Window

arsf / lag

LiDAR Analysis GUI

GNU General Public License v2.0

22 stars 5 forks source link

Persistent Frame in Profile Window #25

Closed ada-foss closed 11 years ago

ada-foss commented 12 years ago

Sometimes, somehow, the profile get's stuck on one particular frame. Refreshing the frame by moving around or zooming though, reveals the frame the user would expect before the program flickers back to the frame it's stuck on.

It's not clear how this is reproduced, may have something to do with using the classification queue.
The program cannot get a new profile and display it, even by moving the viewpoint around, in this state.

ada-foss commented 12 years ago

Current hypothesis: Check Profile::loadprofile, even though it's got a mutex locking the whole method, it could be called with some arguments, block, those arguments become out of date, and then the method unblocks and loads the wrong set of points. Unsure though how this could cause this particular bug.

ada-foss commented 11 years ago

Observed to not be restricted to getting a new profile. Has now occurred when just changing the profile location and moving in the 2d overview window without refreshing the profile.

ada-foss commented 11 years ago

Turns out to occur when: the profile is drawn on the overview, and a point is queried with right-click.

ada-foss commented 11 years ago

Mish-mashed BoxOverlay into doing the job of overlaying the point selection box rather than the LagDisplay::overlayBox method (which probably causes this). That means: 1) All the overlays are being consistently drawn in the same way 2) The point selection box is now something that persists on the dataset and maps to it spatially, meaning its size will subsequently change when you zoom in+out. It might be wise to tweak BoxOverlay to optionally not do this.