Re: [Audacity-quality] linux/win TipPanel patch testing needed (WAS: TipPanel slowness on mac)

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

On Wednesday, October 27, 2010 11:59:41 Michael Chinen wrote:
> Hi Al,
> 
> 2010/10/27 Al Dimond <bus...@gm...>:
> >[...]
> >
> > Here are my results, on Linux. Specifically, Kubuntu 10.10. I'm
> > running a debug build of Audacity under GDB and displaying in
> > Xephyr, a nested X server; the window manager running in Xephyr
> > is not compositing, which may be significant).
> > 
> >> 1.Play with the gain, pan, input/output level sliders
> >> pre-patch.
> >> 2.Create a new project and note if it takes longer than
> >> a second.
> > 
> > Pre-patch, sliders work fine and new project creation is pretty
> > quick within Xephyr, shorter than a second. Since I've heard of
> > performance issues here, and there's window creation happening,
> > I tried outside of Xephyr, under a compositing WM, and it takes
> > around a second to complete project opening. There also is a
> > delay of a few seconds (under a compositing WM but not using a
> > traditional one) when quitting Audacity with about a dozen
> > projects open.
> > 
> >> 3.Apply the patch (from the src dir.)
> >> 4.Play with the gain, pan, input/output level sliders pre-patch.
> > 
> > I got a compile error with the patch -- I noticed that you had
> > said you switched TipPanel to derive from wxFrame on Linux and
> > that wasn't in the patch so I added it, and commented out some
> > Mac-specific stuff in TipPanel::Show(). That makes the compile
> > work... I'm attaching the error text as an attachment so email
> > formatting doesn't get in the way.
> 
> Doh, sorry for the miss.
> 

No prob, that's why we're passing patches! If I had a dime for every 
time I broke the Windows build... well, it would be a very perverse 
incentive.

> >> 5.Create a new project and note if it takes longer than a
> >> second.
> > 
> > Project creation is noticeably faster, both under Xephyr and not.
> > It is almost instantaneous under Xephyr, and pretty snappy
> > anyway outside.
> > 
> >> 6.Play with the sliders on the second project.
> >> 7.Close the first project.
> >> 8.Play again with the sliders on the second project.
> >> 9.Generate some audio, and while the audio is playing move the
> >> gain/pan sliders.
> >> 10.Quit and make sure the application exits.
> > 
> > All this works as expected (I did all this stuff, plus creating
> > about 12 projects and playing with sliders randomly). Once there
> > was a segfault reported on quit but unfortunately I was running
> > outside the debugger -- I sometimes see segfaults when quitting
> > Audacity, so it's not necessarily related, and I haven't found a
> > way to repro it.
> > 
> >> These tests are to try and make it crash or not be drawn and
> >> some stage.  But also please let me know if it looks funny.
> > 
> > Here are the "looks funny issues":
> > 
> > 1. Initially after starting Audacity there's a TipPanel window on
> > the screen (upper-left of my display separate from the Audacity
> > window) with text "Output Volume 000000". Once I drag any slider
> > thumb it goes away. This is true both within Xephyr and outside.
> > 
> > 2. Outside of Xephyr (using KWin with compositing enabled) when
> > the TipPanel appears it grabs focus from the Project window, has
> > a drop- shadow, and has a "pop-in" effect when it appears -- as
> > if it were a normal window and not just a tooltip-like thing.
> > 
> > 3. Within Xephyr (using wm2) it looks like the window decorations
> > are half-drawn. This may be a wm2 bug for all I know (wm2 has a
> > few bugs, and is sort of weird generally).
> > 
> > My guess is that #2 and #3 are both related to my commenting out
> > the Mac-specific stuff. Maybe the changes I made to fix the
> > compile error also caused #1. If you don't have a Linux box
> > handy I might be able to look at this next weekend, but probably
> > not before then, as I imagine I'll have to study some
> > documentation.
> 
> I looked at some documentation and asked around. fixing #1 may be
> easy, but #2 and #3 may not have simple solutions.
> 
> I noticed that linux has wxPopupWindow (mac does not), which is
> what windows uses.  This may be a newer addition that wasn't there
> when the old code was written.
> 
> If you have some time do you think you could try and just put
> "#define USE_POPUPWIN 1" at the top of ASlider.cpp to test if the
> windows version fixes everything on linux?  There's a chance it
> may work and have the right or better behavior.
> 

Setting USE_POPUPWIN #if defined __WXGTK__:

 - Causes a tiny compile error (SetPos needs an extra parameter on 
line 155) that probably would have also occurred on Windows.

 - Fixes all three of the issues from last time. 

 - Adds one issue, however, which is that the window is drawn too low 
on the screen. Probably an easy fix. Since I have Linux and Windows 
installations handy I could try to work out a solution that works 
equally on both of them, but that will be at least a few days.

 - Also, I should check when wxPopupWindow was added to wxGTK. I 
wouldn't want to rely on it if it's too recent, because some people 
still have old wxGTK libraries hanging around.

Al

> I don't have a linux box, but I may install debian on an old mac
> next week.
> 
> Thanks for getting around to testing it so fast!
> 
> Michael