Audacity Bug Summary
••• Introduction •••
••• Keywords •••
    Audacity 3.0.3 development began 19th April 2021

Audacity Bugzilla



Bug 1197 - Extreme zoomed in levels move view, losing cursor or selection.
Extreme zoomed in levels move view, losing cursor or selection.
Status: RESOLVED FIXED
Product: Audacity
Classification: Unclassified
Component: User Interface
2.1.2
Mac macOS
: P2 Repeatable
Assigned To: Paul L
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-12 16:13 UTC by Gale Andrews
Modified: 2018-08-20 11:45 UTC (History)
9 users (show)

See Also:
Steps To Reproduce:
1 Generate a sufficiently long tone. It seems at least 6 minutes is necessary, so generate 10 minutes. 2 Click somewhere in the track, or select about 10 seconds somewhere, then zoom in progressively using the zoom button or shortcut. At the final zoom steps, the view will shift further along the track, removing the cursor or selection from view. 3 LEFT arrow or View > Go to Selection Start / to Selection End do not restore the view position to the cursor or selection start/end, so (unless you are willing to patiently scroll back) the zoom level must be lost in order to restore the cursor/selection to view. 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.
Release Note:
GROUP: Interface * (Mac OS X) '''When zooming in to maximum level (or close to maximum) in tracks exceeding about 6 minutes in length, the view position might move.''' This might un-center or remove the cursor from view, or cause the COMMAND + [ or COMMAND + ] shortcuts to not center or display the selection edge.
First Git SHA:
Group: ---
Workaround:
Closed: 2018-08-20 00:00:00
gale: Regression+
petersampsonaudacity: Test‑OK‑Win?
petersampsonaudacity: Test‑OK‑Mac?


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gale Andrews 2015-09-12 16:13:40 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.
Comment 1 Paul L 2015-09-21 13:01:23 UTC
This was my fault.

Fixed in fork here:
https://github.com/Paul-Licameli/audacity/commit/d776f25830fea3c91b3d2a71329f998e1e5e8312
Comment 2 James Crook 2015-09-21 13:41:30 UTC
We've too many P2s.  I want to clear them.  This one looks straightforward and low risk.
Comment 3 Paul L 2015-09-21 17:34:37 UTC
FYI this bug was introduced early in 2.1.2 by the fisheye preliminaries.  Only a few bugs have been discovered in that.
Comment 4 Gale Andrews 2015-09-24 03:02:27 UTC
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.
Comment 7 Gale Andrews 2015-09-25 11:42:55 UTC
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?
Comment 8 Paul L 2015-09-25 17:26:20 UTC
(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.
Comment 9 James Crook 2015-11-07 16:02:23 UTC
GROUP changed to 'Interface'
Comment 10 Paul L 2016-01-28 09:35:26 UTC
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.
Comment 11 Paul L 2016-01-28 10:42:39 UTC
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.
Comment 12 Peter Sampson 2016-01-31 10:20:07 UTC
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.
Comment 13 Paul L 2016-01-31 14:27:11 UTC
But this bug requires testing on Mac.  There was a report of different behavior.
Comment 14 Steve Daulton 2016-01-31 14:56:10 UTC
Looks OK on Mac (El Capitan)
Comment 15 Peter Sampson 2016-02-01 04:50:16 UTC
(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.
Comment 16 Steve Daulton 2016-02-01 08:13:30 UTC
(In reply to Peter Sampson from comment #15)
Works for me on Linux.
Comment 17 Gale Andrews 2016-02-04 00:02:46 UTC
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.
Comment 18 Steve Daulton 2016-02-04 08:45:44 UTC
(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.
Comment 19 Steve Daulton 2016-02-04 08:49:32 UTC
(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.
Comment 20 Peter Sampson 2016-02-16 08:05:16 UTC
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
Comment 22 Gale Andrews 2016-07-08 13:31:54 UTC
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.
Comment 23 Peter Sampson 2016-07-09 08:20:07 UTC
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.
Comment 24 Peter Sampson 2016-07-09 08:35:50 UTC
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.
Comment 25 Paul L 2016-07-09 09:08:00 UTC
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
Comment 26 Gale Andrews 2016-07-28 12:51:52 UTC
As far as I can tell the mousewheel zooom behaviour has not changed and is not part of this bug.
Comment 27 Peter Sampson 2016-08-01 09:31:23 UTC
See also Bug #1292