[PATCH] dxgi/tests: Avoid an ever chaning value in a dxgi failure message.

[Francois Gouget]

Disclaimer: This is my opinion, all mine.


On Mon, 16 Mar 2020, Henri Verbeet wrote:
[...]
> > > dxgi:
> > > dxgi.c:5063: Test failed: Got unexpected message 0x46, wparam 0, lparam 0x22fa20.
> > > dxgi.c:5063: Test failed: Got unexpected message 0x24, wparam 0, lparam 0x22f690.
> > > dxgi.c:5063: Test failed: Got unexpected message 0x1a, wparam 0x2f, lparam 0x22fa48.
> >
> > The patch was designed to avoid false positives from messages such as
> > WM_DWMNCRENDERINGCHANGED where lparam is 0:
> >
> > https://testbot.winehq.org/JobDetails.pl?Key=67055#k108
> > dxgi.c:5063: Test failed: Got unexpected message 0x31f, hwnd 001C01E4, wparam 0x1, lparam 0.
> >
> > But of course it won't help with unexpected WM_WINDOWPOSCHANGING,
> > WM_GETMINMAXINFO and WM_WININICHANGE messages since lparam is a pointer
> > for those (lparam is sometimes NULL for WM_WININICHANGE). Fortunately
> > these are pretty rare, they happened only three times in the recorded
> > history (vs. 153 instances of WM_DWMNCRENDERINGCHANGED):
> >
> In general, this seems like just papering over the problems.

Sure in an ideal world Wine developers would treat WineTest failures as 
high priority and in a couple of weeks we'd have clean results. Then I 
could simplify the TestBot a great deal: a failure, any failure, could 
only be a NEW failure and the patch would never get committed in the 
first place.

But if that was meant to happen it would have happened YEARS AGO.

And it's not like this is of no consequence. If I understood Alexandre 
correctly at the last WineConf, false positives like these make the 
TestBot unusable for him.

That means he pays no attention to TestBot failures, thus letting in 
more broken tests that add new systematic and intermittent failures, 
keeping the TestBot in its broken state.

So I'm not going to bury my head in the sand and hope Wine developers 
suddenly start fixing more failures than they add.

My goal is to make the Testbot usable for Alexandre and that means 
getting rid of the false positives by any means.

****
* It's only once the incoming stream of broken tests is stopped
* that we have any chance of cleaning the current mess.
****

So the choices are:
1. Fix the failures.
2. Tweak them so the TestBot can distinguish new from old.
3. Remove any test that causes false positives: remove the rot before it 
   spreads.

JUST DO IT NOW!!!


> But in this specific case, do we know why we get those spurious 
> WM_DWMNCRENDERINGCHANGED messages? If they're legitimate, it shouldn't 
> be too hard to specifically filter them out in test_wndproc().

I sure don't and already have enough on my plate with just the 
TestBot tasks.

Reminder:
* https://www.winehq.org/pipermail/wine-devel/2020-February/160464.html
  -> TestBot's WINE TODO LIST: ***** OPEN TO ANY WINE DEVELOPER *****

* https://www.winehq.org/pipermail/wine-devel/2020-February/160559.html
* https://www.winehq.org/pipermail/wine-devel/2020-February/160648.html
* https://www.winehq.org/pipermail/wine-devel/2020-February/160707.html
* https://www.winehq.org/pipermail/wine-devel/2020-March/161374.html

Thanks all for the feedback on these, btw.

-- 
Francois Gouget <fgouget at free.fr>