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

At 9:40 PM +0200 7/9/03, Juliusz Chroboczek wrote:
>TL> The only IOGraphicsLib client I know of besides Apple's
>TL> CoreGraphics window server is XDarwin,
>
>Hmm, so XDarwin hooks in beneath the usual client-side interface...
>Is that always the case, or only in full screen mode?

XDarwin has three modes of operations:

1. Console or IOKit mode - Here XDarwin talks directly to the IOKit 
and takes the place of the CoreGraphics window server. As far as the 
IOKit is concerned, there can only be one window server. This is 
mainly used by people running on pure open source Darwin systems with 
no Apple proprietary GUI goodness on top.

2. Full screen mode - XDarwin requests that CoreGraphics let it take 
over the whole screen. It still needs to use CoreGraphics calls, but 
it can then write directly to the framebuffer.

3. Rootless mode - XDarwin looks like any other application to 
CoreGraphics. There is a one-to-one mapping between top level X 
windows and CoreGraphics windows.

>And where is the CoreGraphics interface documented?  (The one that a
>normal client uses to speak to the window server.)

There are a number of ways to talk to the window server. Actually 
they are all written on top of an Apple internal CGS API. XDarwin 
uses some combination of the following:

1. Cocoa (AppKit) - The preferred method (by us). 
<http://developer.apple.com/documentation/Cocoa/Cocoa.html>

2. Carbon (QuickDraw) - Cocoa does not provide all the functionality 
we need, but the two interoperate so we use QuickDraw for some 
things. This a legacy API from classic Mac OS. 
<http://developer.apple.com/documentation/Carbon/Reference/QuickDraw_Manager/index.html>

3. Xplugin - This is the API developed in cooperation with Apple 
which provides lower level access to the CoreGraphics window server. 
It is supported by Apple only for writing X servers. The only 
documentation is the header file in 
xc/programs/Xserver/hw/darwin/quartz/xpr/Xplugin.h in the top of the 
tree.

Cocoa + Carbon was used in 4.3.0. In the top of the tree we are using Xplugin.

>TL> Yes, Quartz = marketing speak for CoreGraphics.
>
>I'm getting confused.  I had assumed that CoreGraphics window server
>is what they call Quartz Compositor, and that Quartz 2D is
>market-speak for NSBezier and the rest of the geometry handling in the
>client libraries.  Quartz Extreme is an implementation technique for
>CoreGraphics.  Right?  Or am I getting the layering wrong?

Yes, you are right:

Quartz Compositor = CoreGraphics window server
Quartz 2D = CoreGraphics client graphics library (NSBezierPath is 
another API layered on this)
Quartz Extreme = implementation technique

>Now if you could point me to how a client selects for input events (is
>that decoupled from the window hierarchy?) and how switching of mouse
>cursors when the user moves the mouse are done, you'd see me
>overwhelmed with joy.

This depends on the API you are using. :-) Mac OS X has a lot of 
API's to do the same thing because of its mixed heritage.

At the lowest level each application has a Mach port that they 
receive HID (Human Interface Device) events on. The application 
blocks in its CFRunLoop on this Mach port (and possibly others) to 
wait for new events. CFRunLoop is the basis for every application's 
event handling. 
<http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFRunLoops/index.html> 
The window server delivers events to the Mach port for the 
application that owns the active window. Most developers don't deal 
at the level of Mach ports or even setup their own CFRunLoop, so the 
API they are using takes care of the lower level details. For 
example, Cocoa exposes its event handling through the NSApplication, 
NSRunLoop and NSEvent classes while Carbon uses the Carbon Event 
Manager.

Mouse moved events and cursor image switch get special attention. By 
default only the foreground application (which owns the active window 
and controls the menu bar) gets mouse moved events. Applications can 
request to get mouse moved events all the time but this is 
discouraged and rarely used. Only the foreground application can 
change the cursor. Actually, every application can set a cursor image 
to use, but CoreGraphics only uses the one for the current foreground 
application.

The front application switches the cursor in response to mousing over 
an area by receiving an mouse moved event and telling the window 
server to change the cursor. CoreGraphics does not provide a way to 
set a cursor image to use for a particular region of a window. 
However, higher level API's can and do. For example Cocoa NSView's 
can be set to use a certain cursor image whenever the cursor is over 
them. The developer does not need to worry about switching 
explicitly, but there is still a round trip communication with the 
window server involved. Note that this model means that the cursor 
image does not change if you mouse over a special region of a 
background app. First because the background app doesn't know about 
and second because it couldn't do anything about it if it did. This 
is expected behavior for Mac users.

--Torrey