Regression in update region handling

[Maxime Bellengé]

Hello,

This patch introduced regressions :

Moved update region handling to the server
http://cvs.winehq.org/patch.py?id=14725

Since this patch has been applied, I have an application with acts like
a christmas tree :)
The application has owner drawn objects everywhere. What I see is that
every object is painted but once a first object is painted (button or
whatever) when the next one is painted all the rest of the dialog box is
erased and so on. So I can only see the last painted component although
every button is still usable.

This patch is a real nightmare to understand. I tried comparing traces
with +win before and after the patch but with no luck.

I would appreciate if someone can give me an hint on how to find this
bug.

thanks

Max

[Paul van Schayck]

Hey,

On Fri, 21 Jan 2005 18:47:58 +0100, Maxime Bellengé
 wrote:
> This patch introduced regressions :
>
> Moved update region handling to the server
> http://cvs.winehq.org/patch.py?id=14725

A multi-windowed opengl application?

I've got another multi-windowed opengl app as reported a while back.
That app just doesn't draw anything after that patch.
I'm going to retry that application with the current cvs right now.

Paul

[Maxime Bellengé]

On Fri, 2005-01-21 at 19:14 +0100, Paul van Schayck wrote:
> Hey,
>
> On Fri, 21 Jan 2005 18:47:58 +0100, Maxime Bellengé
>  wrote:
> > This patch introduced regressions :
> >
> > Moved update region handling to the server
> > http://cvs.winehq.org/patch.py?id=14725
>
> A multi-windowed opengl application?
>
> I've got another multi-windowed opengl app as reported a while back.
> That app just doesn't draw anything after that patch.
> I'm going to retry that application with the current cvs right now.
>
> Paul

Not at all, it's just an instant messaging application which skins all
of its components.

It's a normal dialog box, where every component is subclassed to skin
them.

Maxime

[Alexandre Julliard]

Maxime Bellengé  writes:
> Since this patch has been applied, I have an application with acts like
> a christmas tree :)
> The application has owner drawn objects everywhere. What I see is that
> every object is painted but once a first object is painted (button or
> whatever) when the next one is painted all the rest of the dialog box is
> erased and so on. So I can only see the last painted component although
> every button is still usable.
>
> This patch is a real nightmare to understand. I tried comparing traces
> with +win before and after the patch but with no luck.
>
> I would appreciate if someone can give me an hint on how to find this
> bug.

It's probably a regression around GetUpdateRect and related functions.
The easiest way to fix it would be to get me a copy of that app, if
that's possible.

[Dmitry Timoshkov]

"Alexandre Julliard"  wrote:
> It's probably a regression around GetUpdateRect and related functions.
> The easiest way to fix it would be to get me a copy of that app, if
> that's possible.

Haven't the code demonstrating the problem already been sent to the list?

----- Original Message ----- 
From: "Nick Hornback" 
To: 
Sent: Tuesday, January 11, 2005 7:20 AM
Subject: Re: Fwd: Foobar2000 audio player Regression
> 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);

[Robert Shearman]

Dmitry Timoshkov wrote:
> "Alexandre Julliard"  wrote:
> > It's probably a regression around GetUpdateRect and related functions.
> > The easiest way to fix it would be to get me a copy of that app, if
> > that's possible.
>
> Haven't the code demonstrating the problem already been sent to the list?
> 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);

I've tried it and it ran without problem. I also tried a few variants, 
without getting an infinite loop.

Rob

[Paul van Schayck]

Hey,

On 24 Jan 2005 12:55:26 +0100, Alexandre Julliard
 wrote:
> It's probably a regression around GetUpdateRect and related functions.
> The easiest way to fix it would be to get me a copy of that app, if
> that's possible.

The program is freely available here (it's an msi installer):
http://library.avsim.net/download.php?DLID=39636
It has been broken since the patch pointed out.

Paul

[Maxime Bellengé]

You can freely get it at 
http://messager.wanadoo.fr/InstallComplete/InstallationMessagerWanadoo3.5.ex...

It's in french sorry.

However, to install it you will need this little patch because the wise
installer uses wininet with an url like this http://myserver/.%5C
\path/to/file. It works on windows but not in wine. I sent a patch a
while ago but it was wrong so it was not applied. This one fix the bug
in the correct place in http.c HTTP_HttpSendRequestW.

Max

On Mon, 2005-01-24 at 12:55 +0100, Alexandre Julliard wrote:
> Maxime Bellengé  writes:
> > Since this patch has been applied, I have an application with acts like
> > a christmas tree :)
> > The application has owner drawn objects everywhere. What I see is that
> > every object is painted but once a first object is painted (button or
> > whatever) when the next one is painted all the rest of the dialog box is
> > erased and so on. So I can only see the last painted component although
> > every button is still usable.
> >
> > This patch is a real nightmare to understand. I tried comparing traces
> > with +win before and after the patch but with no luck.
> >
> > I would appreciate if someone can give me an hint on how to find this
> > bug.
>
> It's probably a regression around GetUpdateRect and related functions.
> The easiest way to fix it would be to get me a copy of that app, if
> that's possible.