The patch that I'll attach here is a major rework of gdkeventloop-quartz.c.

The biggest change in the patch is that it makes use of CFRunLoopObserver
to iterate the GLib main loop when a native OS X run loop is running, as
during a modal operation like window resizing or drag and drop. This means
that windows redraw during resize and DND "drag under" highlighting works.

Another major change is in the communication with the select thread. Rather
than doing synchronous communication where it asks the select thread to
start polling, waits for it to start polling, then after waiting for
events, wakes up the select thread, now it just submits new sets of 
poll descriptors to the select thread asynchronously. 

Doing the thread polling asynchronously is enabled by always doing 
a timeout=0 poll in the main thread first. The timeout 0 poll is needed
in any case to get the behavior of idle functions correct: a low
priority idle function should not fire if there is data waiting on a file 
descriptor.

The asynchronous polling is already a win in reducing context switches,
but the technique becomes even more powerful because we can simply leave
the existing poll going if the new set of file descriptors is the same
as the old one; there are some subtle aspects to this documented in
the comments.

Finally, I added a lot of comments to the existing code as well as the
new code and reordered things a bit, putting the final nail in the
coffin of the usefulness of reviewing this as a diff. (I'll attach
the entire file as well.)

There are also a couple of small changes worth noting:

 * I removed the call to nextEventMatchingMask in gdk_event_prepare();
   I think it was only there by false analogy to the GDK code where
   you have to call XPending() before polling the X file descriptor
   to avoid blocking if there are events in the queue.

 * I removed the code to try and reuse the slot with the dummy
   file descriptor for our wakeup pipe; it was complexity for no
   performance gain. (The GLib poll function used on OS X handles
   -1 fd's fine. This might need rethinking of OS X ever gains a
   native poll() system call.)

 * I made the code always try to pull a Cocoa event, even if the
   dummy poll FD wasn't in the FD set. The dummy poll FD not in
   the set only occurs in the rare case where a higher than default
   sources *has already* said that is ready to dispatch. It should
   be fine to queue up another event in that case too.

One thing to note is that while the Quartz run loop is running, 
GLib timeouts, idles, and IO watches fire and synthetic
events like CONFIGURE events are delivered, but mouse and keyboard 
events are not delivered to GTK+ apps... nothing is pulling them
off the event queue. For window resizing and other "grab" type
applications of manual polling of the event loop this is right;
there may be other situations where we want to deliver all sorts
of events. Investigating run loop modes in detail is likely needed
to figure out exactly what to do.

I'm pretty happy with how this all works... window resizing works
and is pretty smooth, DND is a lot better. It seems robust with
a test program I wrote (will attach), gtk-demo, and my own small 
application. I would not be surprised if there are lurking bugs 
revealed by other larger apps with more Quartz/Cocoa integration.
I've left in the debug prints guarded by a new GDK debug facility
GDK_DEBUG=eventloop.

That all being said, while I think the patch is a good thing and
useful for various reasons, I'm not sure it's the best way to handle 
window resizing. On X, doing layout and repaint during idle during 
window is important because otherwise the window manager can get
arbitrarily far ahead of the application. With Quartz, the frame
is being drawn *by* the application, so doing layout and resize
synchronously in windowDidResize may be best - that will result
in the frame and contents being redrawn as a single unit with
no lag between them. This would require some window system #ifdefs in
gtkwindow.c.