Bugzilla – Bug 1197
Extreme zoomed in levels move view, losing cursor or selection.
Last modified: 2018-08-20 11:45:41 UTC
Reproduced on all platforms, regression on 2.1.1. Occurred before transition to wx3. Could be argued as P3 given pop song length would not be affected, but I don't want this in 2.1.3 so I prefer to rate as P2 rather than promote later.
This was my fault. Fixed in fork here: https://github.com/Paul-Licameli/audacity/commit/d776f25830fea3c91b3d2a71329f998e1e5e8312
We've too many P2s. I want to clear them. This one looks straightforward and low risk.
FYI this bug was introduced early in 2.1.2 by the fisheye preliminaries. Only a few bugs have been discovered in that.
REOPENED. There is a trigger track length or time position of just under 6 minutes that was not apparent to me before. Exceed that length/position and the bug still triggers. For example, generate a tone of 10 minutes, place the cursor using Selection Toolbar at 5 minutes 57 seconds, 000 ms. CTRL + F6 into the track then hold down CTRL + 1 until zoom stops. The cursor is still at 5 mins 57 secs. CTRL + E to refit, click in the wave to get rid of the selection, then place the cursor using Selection Toolbar at 5 minutes 58 seconds, 000 ms. CTRL + F6 into the track then hold down CTRL + 1 until zoom stops. The cursor has disappeared from view. Now look at the visible time range we ended up at (5:57:556000 to 5:57:556122). Somewhere in that range is the "trigger point". If you fit the project and mouse click e.g. at 10 minutes or 15 minutes and CTRL + 1 to zoom in, the view position always ends up at that exact same range. FWIW sample rate plays no part in this. The time/position trigger is the same at 384000 Hz. Paul wrote: > PRL adds: ctrl-[, ctrl-], page up, page down also misbehave at high zoom > level. ctrl-e after selecting a small number of samples also misbehaves. As long as the subject bug does not trigger, I don't see what I would call bad behaviour, now, just before your fix or in 2.1.1 release. If this is some issue that should be logged, please advise.
Better fix in fork here: https://github.com/Paul-Licameli/audacity/commit/4e335af91f84edddec1ddc2782e92f8f69c29350
Applied to master. https://github.com/audacity/audacity/commit/4e335af91f84edddec1ddc2782e92f8f69c29350
REOPENED for Mac only. It is not completely correct yet on Yosemite, so is still a regression on 2.1.1 for that platform. The behaviour seems to be ameliorated in that the view position is not so far off as it was, but the cursor/region still wanders from centre and the cursor can still be lost from view. Generate a 1 hour tone. Click at ~5 minutes and zoom in all the way. This does not lose the cursor, and the cursor is centred in the view. Fitting in window then clicking at positions somewhere somewhere around 6 to 15 minutes then zooming in completely causes the cursor to wander somewhere left or right of centre, but the cursor remains in view. Fitting in window then clicking at positions well beyond 15 minutes then zooming in completely causes the cursor to be lost. Similarly, once you draw a selection with boundaries beyond 6 minutes, the COMMAND + [ and COMMAND + ] shortcuts do not centre the selection edge after zooming in completely. The selection edge will end up off centre, or if the selection is drawn far enough down the track, the shortcuts do not show the selection edge. The fix now works perfectly on Windows and Ubuntu as far as I can see. Why the Mac difference? I have a case sensitive Mac system. Is that relevant?
(In reply to Gale Andrews from comment #7) A calculation that was done all in double precision floating point now involves a conversion to 64 bit integer and back to double again. I suspect some subtle difference in the way the compilers of different platforms handle these numeric conversions might explain it. The original bug fixed here was something grosser than that -- I surely neglected the multiplicative factor mViewInfo.sbarScale in the conversions in the function AudacityProject::SetHorizontalThumb. The project at fault for this is the internal rewrites intended to support the fisheye magnifier, which did not become a new feature yet in 2.1.2. There have been other bug reports related to these rewrites, but still very few.
GROUP changed to 'Interface'
Explaining the numbers in comment #4: The extreme zoom-in level is 6 million pixels per second -- see the constant gMaxZoom. Multiply by 357 seconds, and the result is 0x7fac5380 in hexadecimal, and that fits in 31 bits. Multiply by 358, and it's 0x8007E100 which overflows 32 bit signed representation and can be misinterpreted as a negative. I think this explains why the bad magic happens between 5:57 and 5:58 and is independent of sample rate.
Fixed, I think, at: https://github.com/audacity/audacity/commit/c9fa5000fcc2f914eb370de771b9090b1c07a43c I can't verify on Mac, but it leaves things unbroken on Windows, and restores that calculation to be done again all in double, which seemed to be needed to fix this.
Tested on W10 on audacity-win-rd6b8080-2.1.3-alpha-30-jan-16 Following the steps to reproduce, I could not reproduce the reported symptoms. Looks now to be working as expected.
But this bug requires testing on Mac. There was a report of different behavior.
Looks OK on Mac (El Capitan)
(In reply to Paul L from comment #13) "But this bug requires testing on Mac. There was a report of different behavior." Indeed, but Gale wrote in Comment #0 that this bug was present an all platforms - and therefore it requires testing on all platforms. Remaining outstanding is a test on a Linux platform - once that is done the Gale can presumable close this bug.
(In reply to Peter Sampson from comment #15) Works for me on Linux.
REOPENED for Mac. (In reply to Steve Daulton from comment #14) > Looks OK on Mac (El Capitan) I don't know if that is a Debug build, but at ba7bd5b Release build on El Capitan two commits before last, I can still reproduce everything I wrote in comment #7.
(In reply to Gale Andrews from comment #17) > Fitting in window then clicking at positions well beyond 15 minutes then > zooming in completely causes the cursor to be lost. On El Capitan: With a 1 hour mono track and Audacity running in a window (not maximized) and the cursor position beyond 30 minutes, I can reproduce the bug, though it is not 100% repeatable. The cursor seems to be more likely to move out of view when the cursor position is substantially beyond 30 minutes. I have not been able to reproduce the cursor being lost off-screen when Audacity is maximized, though the cursor position on each zoom-in operation appears more erratic (less centred) than on Linux. Zooming out to "Fit in window" is not required to reproduce the bug, though the cursor is more likely to disappear when there are many zoom-in operations. It is repeatable with as few as three zoom-in operations if the cursor is positioned close to the end of the visible waveform. If the track is very long (tested with 10 hours of mono silence in a non-maximized window, and the cursor position at 9h 40m 11.821s), then the cursor may be lost off-screen after about 25 zoom-in operations, which is 4 zoom levels before maximum zoom. In all cases, zooming out with Command + 3, the cursor comes back into view after zooming out a few zoom levels.
(In reply to Steve Daulton from comment #18) Correction. I can reproduce the issue when Audacity is maximized if I use a 10 hour track.
Testing on Mac El Capitan on 01a95c5-2.1.3-alpha-13-feb-16 I can reproduce this with a 10 hour tone and a one hour tone - but with a 30 minute tone the cursor remains on-screen but does shift about in the final stages. Testing on W10 audacity-win-r2f40664-2.1.3-alpha-14-feb-16 I cannot reproduce this with a one-hour tone - cursor stays on-screen and centred Nor can I reproduce this on a 10 hour tone - the cursor remains Properly on-screen, albeit shifted slightly off-centre
Fixed https://github.com/audacity/audacity/commit/12d22cafc651da72deb867600072628ee048984c
At "c9422aa" this seems to now behave properly on Windows, Mac and Linux. I cannot now reproduce anything in the Steps to Reproduce or comment 7. I tested with Snap To on too. Before resolving I will let someone else test on Mac as well as me, since Steve's and Peter's Macs did not behave exactly as mine.
Testing on c9422aa 08Jul16 on W10 and Mac El Capitan Works fine on both my Macbook Pro and on W10 with the cursor point or selection remaining nicely centered as you zoom in. Testd on one hour and ten hour tones and a three minute song.
previous testing was using the zoom buttons. Also Ctrl(Cmd)+1 and Ctrl(Cmd)+3 for Zoom In/Out do kepp the cursor position or selection on-screen. HOWEVER - on both platforms if I use Ctrl(Cmd)+scroll wheel to zoom the the cursor or selection still disappears off the screen Similarly if I have a one hour tone say select anywher byond ten seconds or so and the use Ctrl(Cmd)+2 for Zoom Normal then the cursor or selection also disappears off the screen (I raised this point in a quality email thread recently). Also using the Zoom Tool moves the cursor or selction off the screen. Surely the current cursor position of selection is the user's current point of interest and we should be doing all we should to keep that on-screen and visible to them. So I believe that this is not fixed and there is more work to be done here.
Disagree that mouse wheel behavior is incorrect. Command + wheel changes magnification, and leaves the time under the cursor unmoved, so that is always the center of expansion or contraction. This overrides the rule that we want to keep the selection on screen. PRL
As far as I can tell the mousewheel zooom behaviour has not changed and is not part of this bug.
See also Bug #1292
