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

[wine-bugs at winehq.org]

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





--- Comment #5 from Anastasius Focht <focht at gmx.net>  2008-07-22 16:55:29 ---
Created an attachment (id=14991)
 --> (http://bugs.winehq.org/attachment.cgi?id=14991)
Recorded call sequences from window proc (expected behaviour)

Hello,

there seem to be at least two issues involved here.
It's a pain to debug this large app with all its unmanaged and managed code so
I sticked with investigating windbg behaviour in hope that's the same issue as
VS.NET 2005

Basically the message sequence for the affected window goes like this (5 calls
of that winproc):

(#1) WM_NCACTIVATE (active = TRUE)
(#2) WM_NCPAINT
(#3) WM_NCPAINT
(#4) WM_NCACTIVATE (active = FALSE)
(#5) WM_NCPAINT

After that sequence, the window refresh is finished.

The info for the affected window (opened via toolbar):

--- snip ---
Title="Scratch Pad - WinDbg:6.9.0003.113 X86"
Parent=00030460
Style=96CD0000
WS_POPUP|WS_MAXIMIZEBOX|WS_CLIPSIBLINGS|WS_CLIPCHILDREN|WS_VISIBLE|WS_SYSMENU|WS_THICKFRAME|WS_CAPTION
ExtStyle=00000100 WS_EX_WINDOWEDGE
Class=WinBaseClass
--- snip ---

Parent (top level):

--- snip ---
Title="WinDbg:6.9.0003.113 X86"
Parent=Topmost
Style=16CF0000
WS_OVERLAPPED|WS_MINIMIZEBOX|WS_MAXIMIZEBOX|WS_CLIPSIBLINGS|WS_CLIPCHILDREN|WS_VISIBLE|WS_SYSMENU|WS_THICKFRAME|WS_CAPTION
ExtStyle=00000110 WS_EX_ACCEPTFILES|WS_EX_WINDOWEDGE
Class=WinDbgFrameClass
--- snip ---

I made note of each user32 call within the app window proc to keep things
simple.

After comparing both sequences, I noticed the following problem:

hRegionClip = NULL;
Flags = DCX_WINDOW | DCX_INTERSECTRGN;

The call to user32.GetDCEx( hWndScratchWindow, hRegionClip, Flags) returned
NULL on Windows XP while Wine returned a valid DC.

After further investigation with google it seems this is some sort of
undocumented behaviour, see:
http://www.virtualdub.org/blog/pivot/entry.php?id=37

--- quote ---
As a side note, a poster on the forum recently helped me track down an
irritating bug in VirtualDub's draggable video frames that was causing some
instability on Win9x platforms.
It happened because of a code fragment that I adapted from the MSDN Library
documentation for WM_NCPAINT that supposedly helps you draw custom window
frames.
Well, the code fragment as given doesn't work, because it lacks an essential
flag.
GetDCEx() simply returns NULL and leaves the error code as NO_ERROR.
You need to add 0x10000, called "an undocumented flag which can magically make
GetDCEx call succeed" in Feng Yuan's GDI book, or DCX_USESTYLE by WINE, for the
function to actually return a usable DC.
It turns out that there is an even worse problem with the code as given because
it causes window regions to be doubly freed!
On Win9x, this results in an occasional crash in 16-bit GDI. (This particular
problem with the WM_NCPAINT example is also colorfully documented in comments
in the WINE source code.) After I fixed this issue, the poster's problem went
away. So if you are using a Win9x platform, expect some stability improvements
in edit mode in 1.6.4.
--- quote ---

I patched dlls/user32/painting.c:GetDCEx for testing purposes but it didn't
solve the endless looping problem.

The call sequences within that app window proc where GetDCEx was involved were
more matching, showing slight improvement over previous situation.
It seems the app directly checked for GetDCEx() returning NULL and took that
into account (expecting such result).
It remains mysterious why a Micro$oft app actually made this call with hard
coded flags when it's expected to return NULL?
Maybe the people there don't talk to each other/suffer from their own MSDN hell
;-)
Maybe some Windows versions show different behaviour?
This has to be added to conformance test ...

Regards


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.