Date: Sun, 25 Jul 2004 16:21:34 -0400 From: Chuck Swiger <cswiger@mac.com> To: Thomas Dickey <dickey@radix.net> Cc: x11@freebsd.org Subject: Re: blue term color in xorg (was: Re: HEADSUP: X.Org conversion) Message-ID: <4104164E.7030102@mac.com> In-Reply-To: <20040725191320.GA25665@saltmine.radix.net> References: <20040725104510.GA10921@saltmine.radix.net> <Pine.GSO.4.10.10407251057140.22396-100000@pcnet5.pcnet.com> <20040725150847.GA19015@saltmine.radix.net> <4103EC99.5040104@mac.com> <20040725180905.GA15760@saltmine.radix.net> <4103FFD4.1000505@mac.com> <20040725191320.GA25665@saltmine.radix.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Thomas Dickey wrote:
>> Why did Apple choose not to use X11 as the window system for MacOS X?
>
> I believe the answer to that is that they already had a lot of code of
> their own which worked with the existing system. (I've also read that
> their internals aren't much to brag about either).
You're probably referring to the QuickDraw toolbox code used by Carbon and the
classic MacOS. The toolbox code was a mildly object-oriented approach based
on Pascal calling conventions which was hardcoded into the boot ROM of the
Apple //gs and then the first Macs. Your criticism of that is likely to be
well-founded :-), but that wasn't what I was talking about.
Mike Paquette was the guy at NeXT who lead the team that wrote much the
Display PostScript system, and then did the same at Apple with Quartz--
anyway, his answer to the question I asked above:
Charles Shannon Hendrix wrote:
> In article <3B759793.BE5A4E87@earthlink.net>,
> Michael Paquette <mpaque@earthlink.net> wrote:
>> Different can of worms. X11 doesn't do what Quartz needs, and
>> 'extending' it would essentially be a new window system with X
>> support tacked on. Apple has elected to do what Quartz needs, and
>> make it possible for someone else to tack on the X11 bits.
>
> What is it that Quartz needs that X11 doesn't do?
What Apple is providing is an Apple-original window system that
is graphics model agnostic, as well as a vector drawing system that maps
very well to PDF, which is a sort of PostScript without the
non-graphical operators. This is packaged under the name 'Quartz' for
easy reference by Marketing types.
The window system is designed to support both buffered (like an
offscreen PixMap) and unbuffered windows, and is graphics model
agnostic, working equally well with QuickDraw, OpenGL, Quartz drawing
engine, and third party solutions, and managing window geometry for the
Classic, Carbon, and Cocoa environments. The server portion is a
hybridization of screen arbiter and compositor models (and if that's all
Geek to you, don't worry about it).
[ ...snip a section on printing and unified imaging models... ]
Things we'd need to add/extend in X Window software
(protocol+server+manager+fonts+...):
1) Extend font server and services to vend outlines and antialiased
masks, support more font types, handle font subsetting.
2) Extend drawing primitives to include PS-like path operations.
3) Add dithering and phase controls.
4) Add ColorSync support for drawing and imaging operations, display calibration
5) Add broad alpha channel support and Porter-Duff compositing, both
for drawing in a window and for interactions between windows.
6) Add support for general affine transforms of windows
7) Add support for mesh-warps of windows
8) Make sure that OpenGL and special video playback hardware support
is integrated, and behaves well with all above changes.
9) We find that we typically stream 200 Mb/sec of commands and
textures for interactive OpenGL use, so transport efficiency could
be an issue.
So, yes, it looks like we can use X for Quartz. All we need do is
define extensions for and upgrade the font server, add dithering
with phase controls to the X marking engine, add a transparency
model to X imaging with Porter-Duff compositing support, make sure
GLX gets in, upgrade the window buffering to include transparency,
mesh warps, and really good resampling, and maybe augment the
transport layer a bit.
Ummm... There doesn't appear to be much code left from the original
X server in the drawing path or windowing machinery, and it doesn't
appear that apps relying on these extensions can work with any other
X server. Just what did we gain from this?
Oh, yeah. My mom can run an xterm session on her desktop now
without downloading a shareware X server or buying a software package.
Been there, evaluated that.
Mike Paquette
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4104164E.7030102>