Re: MacOS X [was: how to write snappy benchmark]

At 7:42 PM +0200 7/7/03, Juliusz Chroboczek wrote:
>DJ> Nextstep/Macos is very solid, correct, and sluggish. Of course this is
>DJ> for many reasons, but the major factors are the drawing model
>DJ> correctness of DPS/DPDF,
>
>Is there any evidence for the existence of DPDF as anything else than
>a marketing ploy (and a reimplementation of NSBezierPath)?  I suspect
>that they're using shared memory pixmaps and doing rendering in the
>client, and that there really is no PDF-based IPC protocol.  Do you
>know otherwise?

DPDF was never a term used by Apple marketing. It is a cute term 
ex-NeXTStep people came up with to accentuate the similarities 
between Mac OS X and NeXTStep.

In any case, your suspicion is correct. Drawing on Mac OS X is done 
by the client into the backing store of the on screen windows. The 
backing store is shared memory with the window server. One trick they 
play to minimize memory footprint is that the window server can 
compress the backing store. The drawing cycle looks like:

Client: "ready to draw on window N" -> Window Server
Window Server decompresses if needed
Window Server: "go for it" -> Client
Client draws
Client: "I damaged this region of the window" -> Window Server
Client: "all done with that window for now" -> Window Server
Window Server sets up DMA transfer to video card of damaged region

The DMA transfer assumes you are using modern hardware and at least 
Mac OS X 10.2. Compression was added sometime in the 10.1 time frame.

--Torrey