[Mono-winforms-list] Question on release notes

[Peter Dennis Bartok]

Before 1.1.16 we stored a WM_PAINT event in the queue whenever we got an ExposeNotify for a window. We had some logic so we'd never put more than one for any particular window in, and instead just updated the existing region if one already existed, but we stored an actual WM_PAINT in the queue and it was processed along with other events in order.

Starting with 1.1.16 we matched MS behaviour. MS uses the event queue only for keyboard/mouse events (I'm simplifying a tad).
Many other messages are sent 'directly' to the window procedure on Windows, via SendMessage (for example WM_WINDOWPOSCHANGED or WM_SETFOCUS, etc).
WM_PAINT events are neither. They are returned via GetMessage, but they don't come from the queue. Instead, GetMessage returns all events from the queue, and once there are no more real events, it looks if there are any windows with invalid content. If it firds one, it generates and returns a WM_PAINT event for each of these windows, and so on. Starting with 1.1.16 our driver behaves like that. 
Around the same timeframe we also added thread-specific message queues. That means that events events are stored in an event queue associated with the thread that created the window, allowing multiple message queues to run in parallel in the same app in multiple threads, again matching MS.

Hope my explanation makes sense. If you still have an old MSDN subscription, search for the "GetMessage and PeekMessage Internals" article, MS seems to recently have removed it from their website or I would have given you a link.

Cheers
       Peter

-----Original Message-----
From: "Dennis Hayes" <dennisdotnet at yahoo.com>
To: <mono-winforms-list at lists.ximian.com>
Date: Tuesday, August 01, 2006 04:17
Subject: [Mono-winforms-list] Question on release notes


  The release notes for 1.1.16 states:
   
  “Repaint logic changed: Instead of having paint events that are contained in the queue and make their way to the head of the queue, we now only generate synthetic paint events for dirty windows once the queue is empty. This matches MS behavior and allows for a more responsive UI if lots of activity (or slow drawing) happens.”
   
  Can someone give me a short explanation of that to me?
  I assume it means something like if there are more than one paint event in the que, you try to combine them together if possible.
   
  I need to explain this to the readers of my “Monkey Business” column, and want to get it right.
   
  Thanks,
  Dennis


------------------------------------------------------------------------------
  Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1¢/min.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-winforms-list/attachments/20060801/624e0521/attachment.html