I've tracked down the flickering and believe it is an annoyance we'll have to deal with until we convert to wx3.  It's related to the progress dialog and the fact that all of the windows are disabled while the progress dialog is active (even it it isn't shown).  The disabling and enabling of the windows cause everything to be redrawn and that is what is causing the flicker.

That in itself isn't the cause of the crashes.  I believe these relate to events getting through while the progress dialog is active since it must yield to allow the dialog to update and accept events (like clicking the Cancel button).  

Unfortunately, I haven't found a solution that will allow the progress dialog to function without yielding.

is wxSafeYield relevant here?

(In reply to James Crook from comment #2)
> is wxSafeYield relevant here?

Not really:

// Yield to other apps/messages and disable user input to all windows except
// the given one
bool wxSafeYield(wxWindow *win, bool onlyIfNeeded)
{
    wxWindowDisabler wd(win);

    bool rc;
    if (onlyIfNeeded)
        rc = wxYieldIfNeeded();
    else
        rc = wxYield();

    return rc;
}

In the progress dialog's case, we've already done the wxWindowDisabler and we call wxYieldIfNeeded, so we've basically done what wxSafeYield does.

The one thing I did recently try was to control the message loop directly, but odd things were still happening.

In ProgressDialog, we disable the application event handler on Windows only.  I'm starting to think that may be appropriate for all plats.

There's also an application level FilterEvent() method that might be useful, but I'd rather not go there if we didn't have to since it would require picking and choosing which events to let through.  It might wind up being the best approach.

But, I'd like to postpone more research until after wx3 since a lot of things will be changing and this might not be a problem anymore.

One of the medium priority tasks on the wxWidgets todo list:

Avoid calling the wxYield family of functions in internal code. wxYield causes problems in combination with pending events leading to all sorts of strange side-effects.

Just some observations from user input on Audacity Forum.

* It's been reported that Audacity 2.1.1 (wx 2.8.12) on El Capitan Public Beta does not rapidly flash the screen, at least "on saving a new recording".

* The subject crashes may be more likely after Audacity has been running a while, especially if sitting idle. 

* There has been speculation about any part App Nap and "Idle Wakeups" may play in crashes. A recent console message at the time a crash occurred when saving/exporting said:

"l8/1/15 9:12:41.000 PM kernel[0]: process Audacity[465] caught causing excessive wakeups. Observed wakeups rate (per sec): 186; Maximum permitted wakeups rate (per sec): 150; Observation period: 300 seconds; Task lifetime number of wakeups: 414213"

If I understand it, Idle Wakeups are the number of times a timer fires in the app. There are a lot of Idle Wakeups when Audacity is not idle e.g. I get between 140 and 230 Idle Wakeups pre second when playing audio. 

That said there is no evidence that enabling "Prevent App Nap" for Audacity does much to prevent the type of crashes noted in this bug.

I believe this to be corrected.  I no longer see it happening now that we're using wx3.

(In reply to Leland Lucius from comment #7)
You're talking about the flicker, Leland, and not the crashes which you established are unrelated? 

Given I (mostly) don't get these crashes any resolution will have to wait for users who get the crashes often to get round to 2.1.2-alpha or release.   

Let me know, I could request some testing.

(In reply to Gale Andrews from comment #8)
> (In reply to Leland Lucius from comment #7)
> You're talking about the flicker, Leland, and not the crashes which you
> established are unrelated? 
> 
> Given I (mostly) don't get these crashes any resolution will have to wait
> for users who get the crashes often to get round to 2.1.2-alpha or release. 
> 
> 
> Let me know, I could request some testing.


Correct, I was referring to the flicker.

I'm really not convinced the crashes were "related" to the flickering, but it would be really nice if you do have a willing tester available to see if they can reproduce the crashes they were experiencing before.

Although there was a Yosemite user who had crashes while Audacity was idle between recordings who does not now get crashes, that improvement seems due to upgrade to El Capitan because 2.1.1 does not crash on El Capitan.

Another Yosemite user who had crashes more like the symptoms in this report still gets the identical spinlock crashes or freezes in HEAD after upgrading to El Capitan. 

So I've REOPENED this with the reference to "flicker" removed from the bug title.

I know I've only been using the new Macbook Pro with El Capitan for a mere six days - but I have done an awful lot of testing ober that time involving saving/importing/exporting and I have not witnessed the reported behaviour.

I will keep an eye out for this

Thanks, Peter.

(In reply to Gale Andrews from comment #10)
> Another Yosemite user who had crashes more like the symptoms in this report
> still gets the identical spinlock crashes or freezes in HEAD after upgrading 
> to El Capitan. 
That user hasn't seen any crashes in 2.1.2 release.

At least six users who had these symptoms in 2.1.1 whom I directed to 2.1.2 release either said the crashes stopped or stopped reporting problems.

I've been doing a lot of testing too around the symptoms of reusing projects for lengthy imports and exports and I don't see the problems. 

So I'm assuming wx3 fixed this and closing it WORKSFORME.