Re: [Audacity-devel] TipPanel slowness on mac

[Al D. <bus...@gm...>]

On Friday, October 29, 2010 15:32:29 Vaughan Johnson wrote:
> On 10/26/2010 8:50 PM, Al Dimond wrote:
> > On Sunday, October 24, 2010 17:41:29 Michael Chinen wrote:
> >> While profiling the mac when you have lots of projects open, I
> >> also noticed that creating a new empty project also takes a few
> >> seconds, so I profiled this as well.
> >> It turns out over 50% of stack frames were landing in the
> >> TipPanel constructor, which is ultimately called by
> >> TrackPanel::MakeMoreSlider making 100 new LWSlider objects.
> >> On the mac there is a #ifdef to make the TipPanel class inherit
> >> from wxFrame instead of wxPanel (linux) or wxPopupWindow(win).
> >> The comment by leland from rev 6371 suggests there's redrawing
> >> problems
> >> 
> >>   6371    llucius #elif defined(__WXMAC__)
> >>   6371    llucius // On the Mac, we use a wxFrame as a wxPanel
> >>   will
> >> 
> >> appear to fall behind
> >> 
> >>   6371    llucius // whatever window it is hovering above if
> >>   that
> >> 
> >> window is refreshed.  A frame
> >> 
> >>   6371    llucius // does not have this problem.  One
> >>   unfortunate
> >> 
> >> side effect is that a shadow
> >> 
> >>   6371    llucius // now appears below the tip panel.
> >>   6371    llucius class TipPanel : public wxFrame
> >>   2146   dmazzoni #else
> >>   1947   dmazzoni class TipPanel : public wxPanel
> >> 
> >> I wondered if this was fixed in new wxMac and changed it to
> >> inherit from the linux wxPanel.
> >> It looks to work alright for me, even when I have audio playback
> >> going and the tooltip touching the moving ruler below it.  With
> >> the change it runs a lot faster, and the delay to open new
> >> projects is barely noticable.
> >> 
> >> On the other hand, I might be misunderstanding what this class
> >> does. Anything I should check for?
> > 
> > I tried to really quickly switch over to wxPanel and got all 200
> > TipPanel windows always visible. I figure I must have done
> > something wrong but I'm not sure what... anyway, I'm sure you've
> > done it right because this problem would be quite noticeable!
> > 
> > If you're wondering what's up with the 100 LWSliders... my memory
> > is a little hazy, but I either created that or tweaked it
> > several months ago to prevent Audacity from choking on projects
> > with thousands of tracks. It appears that in trying to solve a
> > performance problem opening a single really big project I
> > created a problem opening many small projects. 100 sliders, in
> > retrospect, seems excessive.
> 
> That code was originally done a *very* long time ago, so you must
> have tweaked it. There was recently a thread on this list about
> why it was a bad idea, especially as the NoteTrack velocity
> sliders are now treated as pan sliders from among the pool. (And
> it's actually 100 pan sliders and 100 gain sliders, iirc.)
> 

Yeah, the slider pool code is old. I came up with the part where a 
track isn't statically mapped to a slider, because otherwise the 
slider pool becomes enormous when projects get enormous... which was 
just a weird case sent to the list by someone that had accidentally 
created a 65,536-track audio file by having a matrix oriented wrong in 
Octave. I figured it would be nice if we could at least open such files.

> IMO, that whole thing should be re-architected in a much more OOP
> way, so that each track class has its own displayer class that
> knows how many LWSliders they need and what types of LWSliders
> they are (subclasses), so there's not all those type specifiers
> (DB_SLIDER, PAN_SLIDER, et al) and switch statements. The
> efficiency issue might be largely addressed this way, but I think
> there was a Windows-specific issue that should not be paid for on
> all platforms -- maybe pools only on Windows.
> 

I think the Windows-specific issue is that each control is a window and 
there's a hard limit to the number of windows you can have.

> I think it would be a good idea to reduce the size of the pools
> right now, and see if that helps some. I have no idea how many
> users ever have more than 16 tracks, and probably hardly ever near
> 100. I bet 16 or fewer is *far* more common, so I'd say 16 is
> probably a better pool size.
> 

The pool must be large enough that nobody will ever have that many 
tracks vertically on the screen. 100 seems a lot safer than 16 (tracks 
aren't very tall when they're collapsed, some people have portrait-
oriented monitors or otherwise lots of vertical pixels).

It's that design principle -- design it for the biggest people and the 
smallest people, and it should work fine for average-sized people also. 
We should be sure it works well if you have a 2400-pixel high window 
full of collapsed tracks, and also that opening large numbers of tiny 
projects is quick. Then everyone is covered.

 - Al

> - Vaughan
> 
> -------------------------------------------------------------------
> ----------- Nokia and AT&T present the 2010 Calling All
> Innovators-North America contest Create new apps & games for the
> Nokia N8 for consumers in  U.S. and Canada $10 million total in
> prizes - $4M cash, 500 devices, nearly $6M in marketing Develop
> with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel