[Bug 10522] New: endless WM_PAINT loop bug (update regions, queue paint count)

http://bugs.winehq.org/show_bug.cgi?id=10522

Summary: endless WM_PAINT loop bug (update regions, queue paint
                    count)
           Product: Wine
           Version: CVS/GIT
          Platform: PC
               URL: http://www.microsoft.com/whdc/devtools/debugging/install
                    x86.mspx
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: major
          Priority: P2
         Component: wine-user
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]

Created an attachment (id=9265)
 --> (http://bugs.winehq.org/attachment.cgi?id=9265)
trace with WINEDEBUG=+tid,+message,+win,+server

Hello,

I've seen this bug a while ago in other apps but ignored it because it was not
easily to reproduce.
Well until recently when I tested some stuff with windbg from "Debugging Tools
for Windows" (Microsoft).
I used debugging tools version 6.8.4.0 and recent GIT
(wine-0.9.49-302-g58b85bb).

Immediately when a child window was opened using toolbar (register, locals, .. 
whatever), windbg would become unresponsive, eating most CPU.

Happens in both GUI modes - "floating/docking toolwindow" and "MDI emulation.
Though "MDI emulation" is more obvious, it actually shows the endless
refreshing (window caption).

Attached is WINEDEBUG=+tid,+message,+win,+server log.
Additionally I added a trace message which prints the current queue paint count
(when incremented or fetched) which makes some things easier to spot.
Printed as "inc_queue_paint_count: %d" and "get_message_paint_count: %d".

The window hierarchy is as follows:

--- snip ---
*root*=0x10020
   Shell_TrayWnd=0x10022
   WinDbgFrameClass=0x10024
      DockClass=0x10026
      ToolbarWindow32=0x10028
      msctls_statusbar32=0x1002a
   tooltips_class32=0x1002e
   WinBaseClass=0x10030
      ToolbarWindow32=0x10032
      SysListView32=0x10034
          SysHeader32=0x10036
      RichEdit20W=0x10038 
--- snip ---

After the child windows are created the queue paint count never drops to zero,
resulting in endless WM_PAINT processing.
Maybe some update (region) code path missed or flags problem?
I played a bit with ignoring null region updates and it seemed to help a bit
(preventing endless WM_PAINT loop) though other stuff wasn't drawn properly
then.

Regards