On 10/14/10 5:36 PM, Roger Dannenberg wrote:
> I'm even more confused about redisplay now that I was before. First,
> I wonder if anyone else gets this behavior
> (http://www.cs.cmu.edu/~music/audacity/PlaybackRedisplay.html
> <http://www.cs.cmu.edu/%7Emusic/audacity/PlaybackRedisplay.html>):
> during audio playback, the yellow track highlights are "damaged" when
> you move pan or gain controls. Also, the indicator (vertical line) at
> the starting point disappears when you start playing, but reappears
> when you move the gain or pan. I don't see either behavior on my Oct 1
> build on Fedora, but I'm having problems building a completely
> up-to-date version (and I haven't been home to look at Windows).
I now understand a couple of redisplay bugs, but I need some advice on
fixing them.
First, the "damaged" yellow track-selected highlights on OS X are caused
by the display getting drawn with the highlight but the backing bitmap
does NOT have it. As the indicator moves, a vertical column of the
TrackPanel is replaced by pixels from the backing bitmap which is
missing the yellow highlight. The reason the backing bitmap is missing
the highlight is this code (near line 5550 in TrackPanel.cpp):
if (GetFocusedTrack() != NULL)&& wxWindow::FindFocus() == this) {
HighlightFocusedTrack(dc, focusRect);
}
The call wxWindow::FindFocus() returns NULL, e.g. when adjusting a gain
slider. If I change the condition to:
if (GetFocusedTrack() != NULL)) {
The problem goes away, but why was that FindFocus() test there in the
first place? Since this is finding the keyboard focus, I'm wondering if
there's something subtle connected with accessibility or keyboard
shortcuts going on. Can this test be removed?
Second, the cursor sometimes gets erased when you play audio, and it
gets restored when you move a slider. The algorithm is this: (1) erase
the old indicator (the moving line), (2) if the indicator was in the
same place as the cursor, redraw the cursor you just erased, (3) draw
the indicator in the proper location. The bug is that "the same place as
the cursor" is tested by comparing doubles, so if you run the algorithm
when some audio has played, but less than a pixel worth, the old
indicator is no longer in the "same place," but in terms of pixels it
*is* in the same place. The cursor is erased but not redrawn.
The fix could be changing mLastCursor and mLastIndicator from double to
integer and use pixels as the units. However, these get used a lot and
the exact time in seconds may be needed somewhere (I haven't traced all
the dependencies). A simpler fix would be to introduce new members:
mLastCursorPos and mLastIndicatorPos with integer horizontal positions.
I guess a third option would be to quantize mLastCursorPos and
mLastIndicatorPos to pixel offsets before doing the compare.
I would be happy to fix these if I get feedback on (1) do we need to
call FindFocus()?, and (2) of the three ways to fix problem 2, which do
you prefer?
-Roger
|
