Bugzilla – Bug 1886
Sluggish behaviour caused by the large time taken to draw the Track Control Panel
Last modified: 2018-08-20 11:45:19 UTC
The sluggish behaviour make the example tasks in the steps to reproduce effectively unusable. This behvaviour was introduced by the switch to wxWidgets 3.1.1 I've profiled the example of holding down an arrow key to move the cursor and results indicate that a very large amount of time is taken up by the wxWidgets function AlphaBlt(), in src/msw/dc.cpp. This function is called by a number of functions that draw the TCP. I googled the issue, and came across this thread: https://trac.wxwidgets.org/ticket/14403 Right at the end of the thread, there is the suggestion to comment out part of AlphaBlt(). I've tried that, and that seems to have solved the speed problem, although I have not thoroughly checked for any display problems that may have resulted from this. There may well be other ways round this problem other than having to patch wxWidgets.
Additional information. Up until the following commit, holding down the arrow key to move the cursor didn't involve the TCP being redrawn. Author: Paul Licameli <paul.licameli@audacityteam.org> Author date: 2 years ago (23/05/2016 22:56:06) Commit date: 2 years ago (23/05/2016 23:37:42) Commit hash: ba883cbcf46242e9ebc6e15b38f60cc7d871947b Children: 44650ef053 74c8dcf8d3 Parent(s): 5b05f6038d Improve responsiveness of drag seek during click-scrub... .. by refreshing the TrackPanel window less often. But sorting this out would solve to sluggishness of the other example tasks in steps to reproduce.
Peter, why did you change "track control panel" to "track panel" in the title? The problem is specifically the time take to draw the track control panel.
Because the Track Control Panel is specifically the block to the left of the waveform (i,e, the panel that contains the track name, the pan&gain sliders and the mute&solo buttons) - that does not get re-drawn when you make the drags and selections in the waveform The panel that contains the waveforms/selections (that gets re-drwan by the Steps) is called the "Track Panel" AFAIK
(In reply to Peter Sampson from comment #3) > Because the Track Control Panel is specifically the block to the left of the > waveform (i,e, the panel that contains the track name, the pan&gain sliders > and the mute&solo buttons) - that does not get re-drawn when you make the > drags and selections in the waveform It gets redrawn. If it didn't get redrawn, there would not be a problem. > > The panel that contains the waveforms/selections (that gets re-drwan by the > Steps) is called the "Track Panel" AFAIK
(In reply to David Bailes from comment #4) > (In reply to Peter Sampson from comment #3) > > Because the Track Control Panel is specifically the block to the left of the > > waveform (i,e, the panel that contains the track name, the pan&gain sliders > > and the mute&solo buttons) - that does not get re-drawn when you make the > > drags and selections in the waveform > > It gets redrawn. If it didn't get redrawn, there would not be a problem. I've therefore reverted your change > > > > > The panel that contains the waveforms/selections (that gets re-drwan by the > > Steps) is called the "Track Panel" AFAIK
(In reply to David Bailes from comment #1) > Additional information. > Up until the following commit, holding down the arrow key to move the cursor > didn't involve the TCP being redrawn. > > Author: Paul Licameli <paul.licameli@audacityteam.org> > Author date: 2 years ago (23/05/2016 22:56:06) > Commit date: 2 years ago (23/05/2016 23:37:42) > Commit hash: ba883cbcf46242e9ebc6e15b38f60cc7d871947b > Children: 44650ef053 74c8dcf8d3 > Parent(s): 5b05f6038d > > Improve responsiveness of drag seek during click-scrub... > > .. by refreshing the TrackPanel window less often. > > But sorting this out would solve to sluggishness of the other example tasks > in steps to reproduce. The last sentence is wrong. I meant to type: But sorting this out would not solve the sluggishness of the other example tasks in steps to reproduce. Though this commit does mean that unnecessary drawing is done when holding down shift + left/right arrow, as the associated command already calls refresh.
Added another two examples in the steps to reproduce.
Marked as regression and raised to P1.
Following on from a comment to me from James fron TR testing - I tested Recording and playback in this use case with 5 pre-existing tracks - testing on my powerful high-spec SSD laptop 1) The visuals for recording (cursor/waveform) are noticeably more jerky than fresh recording of a single track - but the recording is made intact without apparent dropouts. 2) Playback appears unaffected: normal Play, Scrubbing and TQP all OK
(In reply to Peter Sampson from comment #9) Also with Timer Record on my high-spec laptop with 5 pre-existing tracks teh progress counters are a little erratic missing seconds occasionally - always smooth every second with TR with no pre-existing tracks, The Waiting to start countdown timer is not so affected.
DEVEL - FIX MADE https://github.com/audacity/audacity/commit/4318cb67808461acccd01b6956c57eff08506da7 I confirm the problem in AlphaBlt, and found a fix of setting 24 bit bitmaps, where previously we just used defaults (32 bit). This means we do not need to hack away at wxWidgets to 'fix' the issue. Confirmed that 1-7 are now back to the speed I would expect. I also noticed that start up is snappier.
(In reply to James Crook from comment #11) Testing on W10 with audacity-2.3.0-alpha-64-dcd9368af0a20a500cd338917a2a1e32aedecc8e All 7 Steps to reproduce now work fine for more with smooth slick updates to the visuals. I would prefer David (as the OP) to also test and comment before closing off this bug.
(In reply to Peter Sampson from comment #12) > (In reply to James Crook from comment #11) > Testing on W10 with > audacity-2.3.0-alpha-64-dcd9368af0a20a500cd338917a2a1e32aedecc8e > > All 7 Steps to reproduce now work fine for more with smooth slick updates to > the visuals. > > I would prefer David (as the OP) to also test and comment before closing off > this bug. It looks fine, thanks, David.
