From owner-freebsd-x11@FreeBSD.ORG Sun Jul 25 20:21:43 2004 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0675116A4CE for ; Sun, 25 Jul 2004 20:21:43 +0000 (GMT) Received: from out006.verizon.net (out006pub.verizon.net [206.46.170.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD6F943D1F for ; Sun, 25 Jul 2004 20:21:42 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from [192.168.1.3] ([68.161.120.54]) by out006.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040725202141.CZHL22385.out006.verizon.net@[192.168.1.3]>; Sun, 25 Jul 2004 15:21:41 -0500 Message-ID: <4104164E.7030102@mac.com> Date: Sun, 25 Jul 2004 16:21:34 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Dickey References: <20040725104510.GA10921@saltmine.radix.net> <20040725150847.GA19015@saltmine.radix.net> <4103EC99.5040104@mac.com> <20040725180905.GA15760@saltmine.radix.net> <4103FFD4.1000505@mac.com> <20040725191320.GA25665@saltmine.radix.net> In-Reply-To: <20040725191320.GA25665@saltmine.radix.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out006.verizon.net from [68.161.120.54] at Sun, 25 Jul 2004 15:21:41 -0500 cc: x11@freebsd.org Subject: Re: blue term color in xorg (was: Re: HEADSUP: X.Org conversion) X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jul 2004 20:21:43 -0000 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 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