For me on Windows XP or 7, 1.2.6 can show the waveforms immediately or with say a 10 seconds delay much of the time. 1.3.13 can do so too, but that is probably about one time in ten.  

As I side note, I can't usually afford the time to reboot, shut all apps
down and then work on a long project, but if I do, the drawing behaviour isn't "that" much better, if at all, in 1.3.13 or 1.2.6.

Marked as regression on 1.2. Affected users consistently say 1.2 is faster.

I don't think this is a moonphase bug at all, I get it all the time with longer projects the one or two hours that I regularly record.  

In fact anything that requires a redraw when zoomed out a long way or zoomed-to-fit on projects of that size, for example an Amplify, will cause me to wait many seconds (often up to 20 or 30 seconds).  This has always seemed an unconscionably long time, but it is something /I have come to live with and "expect" as an Audacity bugbear.

The same obtains if you save a long project that is zoomed-to-fit and the later re-open it.  It then also takes a long time to draw the project waveform.

Per comment #3 moonphase->repeatable

Promoted to P2 as agreed in offlists with James and Peter. 

Not sure if this bug has the exact same cause as sluggish editing (bug 765) so leaving them separate for now.

Peter,

Is this still a problem for you with recent builds?

Leland

(In reply to Leland Lucius from comment #6)
Leland,  it certainly seems snappier when redrawing after edits on a long project, testing on a 2 hour project this morning - editing at project fit to screen and also Moving to fit-on-screen to normal zoom level and with zooming out a bit then editing and then going back to fit-to-screen all seems much snappier these days.

The one thing that is still slow is the initial fit-to-screen after making the recording at normal zoom level.  It took 45 seconds for the fit-to-screen to be drawn.

But then shifting from fit-to-screen to normal zoom and then back again therafter is brisk.

Seems to be fixed, so marking as such.

(In reply to Peter Sampson from comment #7)
> The one thing that is still slow is the initial fit-to-screen after making 
> the recording at normal zoom level.  It took 45 seconds for the fit-to-screen 
> to be drawn.
> But then shifting from fit-to-screen to normal zoom and then back again
> therafter is brisk.
Yes I concur, on my two Windows spinning disk machines. The greater speed of fitting in 1.2.6 is very noticeable. Bug REOPENED and steps updated.    

I agree zooming in on a fitted project seems to be much better, so I removed that from the title, which is now "Excessive delays fitting long projects to window, and progress dialog whited out after import or effect."

The whiting out does seem somewhat improved, but not enough to close it. I think users would rather see another 10 seconds on the progress dialogue than see the dialogue white out after apparent completion before the waveform appears.

Created attachment 624 [details]
Slow draw during load

Gale, is this the kind of thing you're seeing?  Sorry the video isn't full screen, but it does show a definitely drawing issue when loading a 2 hour .aup.

I have a 3.6 GHz processor.  I don't notice the long delays, even when opening a project with 16 hours of generated white noise, in a Windows Release build.

I do see long delays in a Debug build, and surprisingly, they involve much copying of wxFileName objects:  interrupting the debugger during the delays always takes me to a stack with that in it.

It might be optimizing the wrong thing to avoid those copies -- who knows what other diagnostic code is compiled out of release versions of wxWidgets -- but I think there is no harm in trying.

No wait, I think I am seeing the delays even in release.  Good, I have something to go on now.

I am seeing the big delays if I open and close my big file of noise repeatedly.  The first two openings are fast, but they seem to get increasingly slow after that.

I see this even in my release builds, and even when I detach the debugger, but oddly I don't see this in downloaded Audacity 2.1.2.  Curious.

So again I am not sure what the exact conditions are for the bug and whether I am fixing the right thing.

Now I think I can reproduce the problem in my release build, even if a sync my source tree to the tag Audacity-2.1.2.  But I can't reproduce it in the downloaded Audacity 2.1.2 !  Presumably the binaries are all the same.

What difference in installations could account for that?

I would like Peter to retest after this commit:
https://github.com/audacity/audacity/commit/9ca1e32e5bcd742f4aaecc435a8d5df44d555544

I am not marking Fix Made yet because there may be several things to do here to improve performance.  But I think this commit should make some significant improvement.

Tested on W10 on audacity-win-r9ca1e32-2.1.3-alpha-07-feb-16

Seems pretty much the same as befor except that long projects seem to open quicke and cleaner.  Testing with a 2 hour project.

1) Project opens at normal zoom - it seems to open much quicker (I have no empiricalevidence for this).  But it is definitely cleaner in that I don'y get the jumbled graphics at the bottom toolbar area of the screen that I've been used to getting for years now with opening large projects.

2) Zoom fit projrcct to scene seems to take as long as in previous versions.  No indication of progress - but if I click a few times on the Audacity window it hazes out pale and I get t the blue spinning donut.

3) After the Zoom, Amplify,  This takes c. 3:30 but ater it's completed the amplify calc at Remaining Time = 0 I also get no indication of progress and again if I click a few times on the Audacity window it hazes out pale and I get t the blue spinning donut.  This recalculation of the drawn image (I assume that's what's taking place) takes another c. 45 seconds

The behaviors in 2 and 3 are what I've always been used to - and got used to putting up with.

(In reply to Peter Sampson from comment #16)
I made a separate issue bug 1319 just for opening.

I don't recall mention of "jumbled graphics" on the toolbar.  That's not the performance problem.  Is that bug listed elsewhere?

Can you do a comparison with the 2.1.2 release to quantify the improvements in opening?

As I said, I did some but not all of the work that looks promising, but this problem might depend much on individual machines' characteristics.  I suspect subtleties of memory fragmentation and cache usage.

No I've never mentioned "jumbled graphics" before, because I could never capture a screen-shot - it's just something else I've got used to and ignore over the years.

Will try to do some proper timed comparisons versus 2.1.2 - but I'm assuming that I need different 2-hour projects to avoid caching issues?  The very earliest I can get to this is tomorrow probably.

(In reply to Peter Sampson from comment #18)
No, I am referring to processor cache locality.  Please test the same large project with different executables.

Testing on 2.1.2 versus audacity-win-r9ca1e32-2.1.3-alpha-07-feb-16
with a 2-hour project

Shows no speed improvement in Fit Project from normal F2 zoom level - both weigh in at c. 44 seconds.

Similarly the redraw of the waveform after after a Noise Reduction and an Amplify both take c. 44 seconds on both executables.


For the user there are a number of disconcerting things going on here:

1) During the Amplify/NR on the two hour project the user is presented with a countdown for the effect in a progress dialog.

2) When the countdown reaches zero the progress dialog disappears - but Audacity just sits there (user thinks "whats happening") as there is no progress dialog for the redraw, even though the redraw is fairly time consuming.  Nor is is there any other visual cue to indicate that Audacity is actually doing anything.

3) User gets impatient and clicks 3 or 4 times in the Audacity Window.

4) Then it gets really disconcerting as this is when the Audacity window gets whited out (actually paled out) and the user gets a message at top left of the Window to say "Audacity not responding".


So while it would be nice to improve the speed of the redraw for Fit Project for long projects and then the redraw on subsequent effects that change the waveform.  I am more concerned that the GUI does not it inform the user that Audacity is actually working on something, what it's doing and how long it might take - i.e. the redraw itself could do with a progress dialog.

But note that the NR takes 7 minutes or so and the Amplify 4:30 (on both executables) or so - thus the extra 45 seconds is a small part of that - but a progess monitor would still be useful to the user.

I have copied the above notes from my Comment #20 to Bug #217 Progress dialogue/better handling needed for waveform drawing

(In reply to Peter Sampson from comment #20)
I compared 2.1.2 release with audacity-win-r79a25b1-2.1.3-alpha-21-apr-16.zip on Windows 10 (2.4 GHz, dual core, 6 GB RAM, HDD). I prepared a 10 hour mono noise track, fitted to window and saved project. I opened the project in 2.1.2 then ran Normalize on the complete track. I quit and repeated the process another two times. Then I did the same for 2.1.3-alpha.   

I saved to C:\ (80 GB free before saving, only system files and folders are on C:\ apart from the AUP).

Not responding/whiteout duration before waveform of AUP appears:
2.1.2: 30 seconds, 35 seconds, 35 seconds   
2.1.3-alpha: 12 seconds, 15 seconds, 18 seconds.

Not responding/whiteout duration after Normalize completes:
2.1.2: 25 seconds, 30 seconds, 30 seconds
2.1.3-alpha: 30 seconds, 40 seconds, 30 seconds.   

So for some reason I see a strong improvement after opening but not normalize.   

Next I zoomed into the project six times, deleted a few seconds, saved and closed.  

Times to open zoomed in project:
2.1.2: 5 seconds, 5 seconds, 4 seconds, no whiteouts
2.1.3-alpha: 5 seconds, 6 seconds, 5 seconds, no whiteouts. 

Times to then fit the project     
2.1.2: 2 seconds each time, no whiteouts
2.1.3-alpha: 2 seconds each time, no whiteouts.

If I then zoom in six times and fit the project, both 2.1.2 and 2.1.3-alpha take about 2 seconds each time, no whiteouts.  

So is this now a bad test of the fit, because of caching somewhere, and I should reboot? I'll try that tomorrow, opening a project that was saved in Zoom Normal state.

It seems I accomplished something for bug 1319 but not for this original one.

(In reply to Paul L from comment #23)
Still happening in 2017

(In reply to Peter Sampson from comment #24)
Remains a problem on my old laptop with just a spinning metal disk for longer 1-3 hour projects.

But on my new HP laptop with the 256GB SSD and 1TB spinning metal disk - a three hour project opens straight away with no delay - no unsetting graphics (it's set up with the OS apps and active data including active Audacity projects all on the SSD)

This problem is exacerbated by the fact that there is no progress indicator to indicate progression through the "open" process (as there is with the application of effects on such large projects - which serve to reassure the user that something is happening and progress is being made). 

Accordingly I would recommend that we add a Progress Bar to the "Open" process.

Note that Import already has such a Progress Bar.

*** Bug 1339 has been marked as a duplicate of this bug. ***

Bug #1319 looks to be a duplicate of this one

Testing on 2.2.2 W10 on my Laptop with the 256 GB SSD 

With this powerful fast PC I see no delays or whiteouts in any of the Steps to reproduce


As with companion bug #1310 It seems to me that for a large data set - you need a powerful PC.

I can recall no recent complaints about this on the Forum so I am going to close this as WORKSFORME