Fwd: Foobar2000 audio player Regression

[Nick Hornback]

I originally posted this to the -users list, but I was
contacted by Robbert Xerox, who had the exact same
issue, and thus far nobody has replyed in the users
list, so maybe it will get more attention here.
> Foobar2000 worked virtually perfectly in the

20041019
> release (aside from some comctrl32 repainting issues
> -- which native comctrl32.dll fixed), but in

20041201
> it is completely unuseable. Two major problems:
> - The toolbars are completely gone. They are

sort-of
> displayed when they get activity via mouse-press or
> whatever, but they do not repaint correctly at all.
> See this screenshot for details:
>

http://img20.exs.cx/my.php?loc=img20&image=w1ifoobar.gif
> - It takes 100% cpu. In the 20041021 release, it
>
> hovered around 5% cpu (on my athlon 64 3200+), which
> was excellent because that beat most native linux
> audio players.
> The console log is as follows (no errors or

warnings):
> fixme:hook:NotifyWinEvent (32780,0x10026,-4,1)-stub!
> fixme:hook:NotifyWinEvent (32780,0x10026,-4,1)-stub!
> fixme:hook:NotifyWinEvent (32780,0x10026,-4,2)-stub!
> fixme:hook:NotifyWinEvent (32772,0x1002a,-4,0)-stub!
> fixme:hook:NotifyWinEvent (32772,0x1002c,-4,0)-stub!
> fixme:win:SetWindowTextA cannot set text "" of other
> process window (nil)
> Does anyone know what is going on here?

I have since found out that if you use a the builtin
comctrl32.dll, none of the window repaints at all. In
previous wine releases, using the builtin
comctrl32.dll would just create minor glitches (ex.
the status bar wouldn't update).

__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Helps protect you from nasty viruses. 
http://promotions.yahoo.com/new_mail

[Robert Shearman]

Nick Hornback wrote:
> I originally posted this to the -users list, but I was
> contacted by Robbert Xerox, who had the exact same
> issue, and thus far nobody has replyed in the users
> list, so maybe it will get more attention here.
> > Foobar2000 worked virtually perfectly in the
>
> 20041019
> > release (aside from some comctrl32 repainting issues
> > -- which native comctrl32.dll fixed), but in
>
> 20041201
> > it is completely unuseable. Two major problems:
> > - The toolbars are completely gone. They are
>
> sort-of
> > displayed when they get activity via mouse-press or
> > whatever, but they do not repaint correctly at all.
> > See this screenshot for details:
>
> http://img20.exs.cx/my.php?loc=img20&image=w1ifoobar.gif
> > - It takes 100% cpu. In the 20041021 release, it
> >
> > hovered around 5% cpu (on my athlon 64 3200+), which
> > was excellent because that beat most native linux
> > audio players.
>
> I have since found out that if you use a the builtin
> comctrl32.dll, none of the window repaints at all. In
> previous wine releases, using the builtin
> comctrl32.dll would just create minor glitches (ex.
> the status bar wouldn't update).

The drawing issues look like a regression in the toolbar code. I'll take 
a look.

Rob

[Paul van Schayck]

Hey Rob,

On Wed, 08 Dec 2004 17:08:03 -0600, Robert Shearman  wrote:
> The drawing issues look like a regression in the toolbar code. I'll take
> a look.

A regression test showed the "menu not being drawed" issue was caused
by this patch:
http://cvs.winehq.org/patch.py?id=14371
http://www.winehq.org/hypermail/wine-cvs/2004/10/0395.html

Hope that helps you,
Paul van Schayck

[nx12]

On vie, 2004-12-10 at 10:37 +0100, Paul van Schayck wrote:
> A regression test showed the "menu not being drawed" issue was caused
> by this patch:
> http://cvs.winehq.org/patch.py?id=14371
> http://www.winehq.org/hypermail/wine-cvs/2004/10/0395.html

Reverting this patch helped me with foobar. Thank you, Paul. Hope this
will be fixed in next wine release.

[Nick Hornback]

> > Foobar2000 worked virtually perfectly in the
> > 20041019 release, aside from some comctrl32
> > repainting issues -- which native comctrl32.dll
> > fixed. In 20041201 it is completely unuseable. Two
> > major problems:
> > - The toolbars are completely gone. They are sort
> >
> > of displayed when they get activity via mouse-press
> > or whatever, but they do not repaint correctly at
> > all. See this screenshot for details:

http://img20.exs.cx/my.php?loc=img20&image=w1ifoobar.gif
> > - It takes 100% cpu. In the 20041019 release, it
> >
> > hovered around 5% cpu (on my athlon 64 3200+),

which
> > was excellent because that beat most native linux
> > audio players.
> >
> > I have since found out that if you use a the

builtin
> > comctrl32.dll, none of the window repaints at all.
> > In previous wine releases, using the builtin
> > comctrl32.dll would just create minor glitches (ex.
> > the status bar wouldn't update).
>
> The drawing issues look like a regression in the
> toolbar code. I'll take 
> a look.

Is there any update on this? I just checked out the
cvs  a couple days ago and both issues (toolbars don't
repaint, and 100% cpu useage) are still present. The
faulty patch, http://cvs.winehq.org/patch.py?id=14371
as mentioned earlier still seems to be applied.

-- Nick Hornback
> Rob

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

[Robert Shearman]

Nick Hornback wrote:
> > > Foobar2000 worked virtually perfectly in the
> > > 20041019 release, aside from some comctrl32
> > > repainting issues -- which native comctrl32.dll
> > > fixed. In 20041201 it is completely unuseable. Two
> > > major problems:
> > > - The toolbars are completely gone. They are sort
> > >
> > > of displayed when they get activity via mouse-press
> > > or whatever, but they do not repaint correctly at
> > > all. See this screenshot for details:
>
> http://img20.exs.cx/my.php?loc=img20&image=w1ifoobar.gif
> > > - It takes 100% cpu. In the 20041019 release, it
> > >
> > > hovered around 5% cpu (on my athlon 64 3200+),
>
> which
> > > was excellent because that beat most native linux
> > > audio players.
> > >
> > > I have since found out that if you use a the
>
> builtin
> > > comctrl32.dll, none of the window repaints at all.
> > > In previous wine releases, using the builtin
> > > comctrl32.dll would just create minor glitches (ex.
> > > the status bar wouldn't update).
> >
> > The drawing issues look like a regression in the
> > toolbar code. I'll take 
> > a look.
>
> Is there any update on this? I just checked out the
> cvs  a couple days ago and both issues (toolbars don't
> repaint, and 100% cpu useage) are still present. The
> faulty patch, http://cvs.winehq.org/patch.py?id=14371
> as mentioned earlier still seems to be applied.

I took a quick look at it, but I came up against a number of problems:
1. The application seems to be half open-source, but the user interface 
doesn't seem to in the half that is opened.
2. I assume patch linked to above is correct, but the app isn't calling 
BeginPaint, which it should.
3. The app uses MFC and BeginPaint should probably be called by one of 
the MFC base classes, but tracing code paths through MFC takes ages.

If you can get the programmer who wrote the application to reduce the 
problem down to a simple test case with source, I might have some more 
luck. Otherwise, I don't have the time to investigate it.

Rob

[Nick Hornback]

> I took a quick look at it, but I came up against a
> number of problems:
> - The application seems to be half open-source, but
>
> the user interface 
> doesn't seem to in the half that is opened.
> 2. I assume patch linked to above is correct, but
> the app isn't calling 
> BeginPaint, which it should.
> 3. The app uses MFC and BeginPaint should probably
> be called by one of 
> the MFC base classes, but tracing code paths through
> MFC takes ages.
>
> If you can get the programmer who wrote the
> application to reduce the 
> problem down to a simple test case with source, I
> might have some more 
> luck. Otherwise, I don't have the time to
> investigate it.
>
> Rob

I just mentioned the problem on foobars irc channel,
and someone posted some sample WM_PAINT code that I
believe is what you might have been looking for
(BeginPaint isn't used anywhere). According to the
foobar devs, and I've heard this from previous threads
in the foobar forums when wine had issues with
repainting the playlist, is that BeginPaint is not
nessesary, and that seems to be a recuring problem
with wine.

Attached is the code that was posted in the irc
channel. I'm not enough of a dev to make sense of it,
but hopefully it'll help.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

case WM_PAINT:
    {
     struct
     {
      RECT rcPaint;
      HDC hdc;
     } ps;
     if (!GetUpdateRect(wnd,&ps.rcPaint,0))
      GetClientRect(wnd,&ps.rcPaint);
     ps.hdc = GetDC(wnd);

int min,max;
     min = display_offset + (ps.rcPaint.top/item_height);
     max = display_offset + (ps.rcPaint.bottom/item_height) + 2;
     int n;
     if (max>get_count()) max = get_count();
     for(n=min;n<max;n++) repaint(n,ps.hdc,&ps.rcPaint);

int blank_top = (get_count() - display_offset) * item_height;
     if (blank_top < ps.rcPaint.bottom)
     {
      RECT temp = ps.rcPaint;
      temp.top = blank_top;
      HBRUSH br = CreateSolidBrush(cfg_playlist_background);
      FillRect(ps.hdc,&temp,br);
      DeleteObject(br);
     }
     ReleaseDC(wnd,ps.hdc);
     ValidateRect(wnd,&ps.rcPaint);