3

Please correct me if I am wrong. My understanding is that Mac OS X has a WindowServer process that composites windows from all applications and draw the final composite image on screen. The question is then where WindowServer process obtains the "windows data" (in some form such as bitmaps) of other applications. Is it implemented through shared memory mechanism between applications and the WindowServer process? Any info or pointers/documentations on this would be helpful!

Also, is iOS implemented similarly regarding this aspect?

Thanks!

zack
  • 335
  • 3
  • 13

1 Answers1

12

The mechanism by which your window bitmaps get marshaled to the WindowServer process is an undocumented implementation detail that is effectively "opaque", so even if you went to the effort to figure out how it works right now, it might change from release to release. That said...

If I had to take a guess on how it works, my guess would be that there is a block of shared memory that backs each window, and when your window goes to draw its view hierarchy, [NSGraphicsContext currentContext] is set up to point to a CGContext that's backed by that block of shared memory. When the window drawing sequence finishes, I would guess that one or more mach messages are sent from your process to the WindowServer process to tell it that it's time to present the just-drawn frame.

On iOS, it seems the Springboard process plays the window server role, and I imagine works similarly, however again, all these details are undocumented implementation details and therefore opaque. Since CoreGraphics is present in both OSX and iOS, it stands to reason that the mechanisms are similar.

You can find some evidence for this hypothesis using vmmap and the debugger (or dtrace). For instance, you can set up breakpoints (or dtrace probes) on all the different functions that can map virtual memory regions into your process (mmap, vm_allocate, etc.) then do a before/after comparison of vmmap output across the act of opening a new window. You'll see that there are new VM regions that have been mapped into your process, but you'll not have seen any corresponding hits on your breakpoints/dtrace probes (i.e. nothing in your process mapped these regions). This is evidence of the window server process having mapped regions of shared memory into your process. The meta-info about these regions is communicated to your process using mach messages (most likely). Trying this on a trivial sample application, opening a new window and looking at the difference in vmmap output shows this region that is very likely the backing store for our recently created window:

CG backing stores      00000001c73f2000-00000001c74cc000 [  872K] rw-/rw- SM=SHM
ipmcc
  • 29,581
  • 5
  • 84
  • 147