QuickDraw GX
From Wikipedia, the free encyclopedia
QuickDraw GX was a replacement for the QuickDraw (QD) 2D graphics engine and Printing Manager inside the "classic" Mac OS. Although GX was based on the same general geometry and dimensions of the original QD engine, the underlying drawing platform became a resolution-independent object oriented retained mode system, making it much easier for programmers to perform common tasks. Additionally, GX added various curve-drawing commands that had been lacking from QD, as well as introducing TrueType as its basic font system.
While GX certainly addressed many of the problems QD had not, by the time it was available most developers had already developed their own solutions to these problems anyway. GX also suffered from causing a number of incompatibilities in existing programs, notably those that had developed their own QD extensions. This, coupled with opposition from the developer market and a lack of communication from Apple about the benefits of GX and why users should adopt it, led to the technology being sidelined. While GX was eventually "killed" with the purchase of NeXT and the eventual adoption of the Quartz imaging model in Mac OS X, many of its features are now standard in the current Macintosh platform.
Contents |
[edit] History
[edit] Problems with QuickDraw
The original QuickDraw was based on a model similar to actual painting; the programmer set up a global "state" by selecting settings such as the font, brush size and pattern, and then called a series of drawing operations based on this state – draw a line to this point, now this point, now draw "Hello World" here. The available commands were fairly advanced for the era, when many machines did not even include a "lineto" command, but critically the font system was based on bitmaps instead of outline fonts. A less critical problem was that QuickDraw did not contain any sort of advanced curve-drawing routines, although this was true for most other systems as well.
In order to squeeze as much performance out of what was an overloaded machine, the Mac OS (or simply "System" as it was then known) shared a small amount of memory between the application and System that contained the drawing state data. This was located at the top of the application's address space, represented as a series of arrays, one entry storing the state of every window the application had open. This way the programmer could draw into a series of windows without having to manually "switch state", a task the operating system was able to do for them.
This organization led to a serious problem when Apple started to introduce multitasking features into the System. Since there was a single global state being shared between the program(s) and the System, there was no easy way to introduce protected memory, which would require the memory in question to be expensively "mapped" back and forth, affecting performance. Additionally, since the structures themselves were open to direct manipulation by the programmer, it would be extremely easy for one program to accidentally end up setting state in another. These problems were the primary reason Apple was unable to support preemptive multitasking in the System, and were forced to use cooperative multitasking instead. Worse, the lack of protected memory increasingly caused stability problems as the size of the operating system grew.
Compounding these problems was the introduction and widespread use of PostScript (PS) in the desktop publishing market, a market Apple practically "owned". PS included many features not found in QD, notably Bézier curves and outline fonts. The entire imaging model was also quite different, being based on a floating point coordinate system, one whose layout was "flipped" in comparison to QD. The coordinate system itself did not have a "natural resolution" either, whereas QD scaled everything based on 72 dpi. Developers wishing to make a PostScript-compatible program had to write their own handlers for supporting these functions, and then laboriously convert the QD layout into the PS model. This conversion was fraught with problems, and often broke the WYSIWYG editing that the Mac had striven for.[citation needed]
QD also had a number of mundane usability problems. For instance, the original printing system had been created in an era when printers were attached directly to the machine, so the printer selection system consisted of a program known as Chooser to select which port it was attached to. With the introduction of networked printers – largely through Apple's own efforts – tying the machine to a single printer at the time was a huge annoyance. Users repeatedly asked for a new system that knew about multiple printers, and displayed them right on the desktop.[citation needed]
[edit] Creating GX
GX appears to have started in a roundabout fashion, originally as an outline font system that would be added to the Mac OS. Included in the font rendering engine were a number of generally useful extensions, notably a fixed point coordinate system and a variety of curve drawing commands. The system also included a system for "wrapping" existing PostScript Type 1 fonts into its own internal format, which added bitmap preview versions for quick on-screen rendering. This project later took on an expanded role when Apple and Microsoft agreed to work together to form an alternative to PostScript fonts, which were extremely expensive, creating the TrueType effort based on Apple's existing efforts.
Another project, apparently unrelated at first, attempted to address problems with the conversion from QuickDraw into various printer output formats. Whereas developers had earlier been forced to write their own code to convert their QuickDraw on-screen display to PostScript for printing, under the new printer architecture such conversions would be provided by the OS. Additionally the new system was deliberately engineered to be as flexible as possible, supporting not only QD and PS printers, but potentially other standards such as Hewlett Packard's PCL as well. The system also supported "desktop printers", the long sought-after feature missing from QD, and added improved printing dialogs and controls.
It is not clear when the projects merged, but this was a common theme in Apple at the time. Middle-managers were involved in an intense turf war for much of the late 80's and early 90's, gathering projects together into "über-projects" that contained enough important code to make them "unkillable". Sadly this often delayed the projects dramatically; one component running behind schedule forced the entire collection to be delayed so they could be released "complete". QuickDraw GX was one such victim, and delays and changes of direction in TrueType and other problems greatly delayed the introduction of GX.
Discussions of GX technology started appearing in various trade magazines around 1992, notably Apple's own develop. At the time it appeared release was imminent, perhaps late 1992 or early 1993.
[edit] Release and use
GX was initially released in about January 1995, as a separate package. Version 1.1.1 was bundled with System 7.5 later that year. The system was received with a dull thud. The package was large enough to strain the memory of most existing Macintosh computers of the era, and arguments like "you can now print to PostScript" were less than impressive considering many existing programs had already added such support. Users and developers generally ignored GX, and a "market" for the system simply never appeared.
There appears to be no one reason for GX's failure in the market, but certainly a number of them conspired to lessen its appeal. For one thing, GX was very large, requiring what was then a lot of memory in order to run effectively. Speed was also an issue, limiting it to running only on Macs with a Motorola 68020 or better. Given that the installed Mac base at the time still contained large numbers of machines like the Mac Plus, these requirements restricted the number of machines it could run on. When it was first released, one review noted QuickDraw GX isn't for everyone and requires more RAM than many Macs have to spare. [1]
Additionally, the API for the system was very large, filling several books. Implementing a GX program was no easy feat, even though the development was supposed to be much easier. This was not a problem of the GX architecture itself, but a side effect of the "all inclusive" nature of the system – a problem most Apple products of the era suffered from (see PowerTalk for instance). As a result the developer appeal was limited; a lot of effort would be required to use the system in programs, and the resulting application could only run on a subset of the installed base – let alone the upcoming Windows 95, which was in the midst of its media blitz. The number of GX-based (as opposed to GX-compatible) programs could be counted on one hand.
Additionally, the change in printing systems presented serious real-world issues. While PostScript printing had never been easy, over the years since the release of the original LaserWriter developers had built up a library of solutions to common problems. With the change in architecture for GX, most of these stopped working. New "GX drivers" were needed for printers as well, and Apple didn't supply drivers for all of their own printers, let alone any 3rd party ones. Printing problems were endemic, and so difficult to fix that users often gave up on the system in frustration.
User uptake of GX was very close to zero, as was the case for most of the new technologies Apple released in the early 1990s. It may have seen widespread use as a part of the Copland project, but it seems just as likely to have ensured the eventual failure of it, given its problems. Although Apple continued to state GX was the future of graphics on the Mac, by 1995 it was clear they were no longer "pushing" it, frustrating its supporters.
Mac OS 8 dropped support for the GX printing architecture, though the text management and color management architectures survived. Elements of the text management architecture became part of the TrueType Specification and elements of the color management architecture became part of the International Color Consortium specification. With the advent of Mac OS X, portions of GX live on in Apple Type Services for Unicode Imaging (ATSUI), and in ColorSync, whose file format is identical to the original format developed for GX.
[edit] Description
[edit] Graphics
QuickDraw GX is based on an object oriented model in which graphics objects are aware of and responsible for their own state. Unlike QuickDraw, there is no universal "state", every drawing command can re-construct the state from data stored within it, or various "parent" objects. For instance, a programmer could build a redBox object that first sets the color to red, and then draws a square. From that point on the program no longer has to explicitly set the color before drawing, the GX system itself will always correctly set the drawing color when asked to draw a redBox, and reset it when finished. Since this state was private, and sent to GX if and when needed, GX theoretically allowed the Mac OS to support protected memory, as state was no longer shared directly between the programs and graphics system.
This contrasts strongly with the original QuickDraw, where the programmer was responsible for all state changes. For instance, if one were to draw a redBox and then a series of lines, the lines would also appear in red unless the programmer explicitly changed the color first. The advantage to this approach is that it minimizes the number of commands needed to set state; the programmer can organize drawing to draw groups of similarly styled objects at the same time and thereby save time. The disadvantage of this approach is that it is extremely easy to "forget" to change state and end up causing problems, so easy that most programmers simply saved and restored the complete state before every drawing command, thereby dramatically lowering performance.
The drawing state under GX was hierarchical. A default drawing mode was created with every window, as it was under QD, and drawing objects with no other state changes would use these defaults. The programmer could then change state in the objects themselves, as in our redBox example, or alternately change the state of all drawing by setting the state in the window object. GX objects could be easily collected into groups, themselves objects, allowing the state to be set for an entire complex object.
On part of the overall drawing state was the gxMapping. This was a 3-by-3 matrix which could express arbitrary linear transformations in two dimensions, including perspective distortions. All GX objects had an associated mapping as part of its drawing state, which allowed for things like rotations and translations. Although all of this state was held in the gxMapping for that object, GX also provided "wrapper" commands like "rotate" to make the API simpler to use.
Unlike QuickDraw, QuickDraw GX allowed for fractional coordinates. However, these were fixed-point values, rather than floating-point. At the time GX was being developed (late 1980s to early 1990s), there was still a significant performance penalty in using floating-point arithmetic.
The GX graphics architecture was built around a number of types of objects which were premade, though a full set of API calls was available for examining and manipulating them:
- a gxShape defined the basic geometry of a shape (for example, coordinates of control points for a curve, or the text content of a text object).
- a gxStyle defined elaborations of the basic shape geometry, such as line thickness, cap and join styles, fill pattern and text font.
- a gxInk specified how pixel values were to be computed when rendering the shape: besides specifying a basic color for the shape, this also included an elaborate transfer mode structure that could define a wide variety of functions of the initial and final destination pixel value.
- a gxFont represented a font, either one installed for systemwide use, or one installed on-the-fly by the current application for its own use. API calls allowed the interrogation of the properties of a font, including the determination of what encodings (Unicode, language-specific etc) it might support.
- a gxProfile was a representation of a ColorSync color profile, used as part of the specification of a color for drawing. GX integrated full support for color matching at all stages of the drawing process, as well as support for non-RGB color specifications (such as HSV, YUV and CIE XYZ).
- a gxTransform determined the relationship between the shape and the display device. Besides the clipping path and the gxMapping that transformed the shape before displaying on the output device, this object also specified hit-testing information that controlled responses to user clicks within the area of the shape.
- a gxViewDevice represented a block of pixel memory into which drawing would be rendered. This could be an actual on-screen display, or an offscreen block of memory. GX supported all the QuickDraw pixel layouts; this allowed both a GX view device and a QuickDraw GrafPort to point to the same pixels, thereby allowing applications to mix both sets of drawing calls.
- a gxViewPort was a logical destination for drawing. A gxTransform could specify a list of more than one of these; the shape would be drawn into all of them in a single GXDrawShape call.
- a gxViewGroup represented the connection between view devices and view ports. Each view port had a gxMapping specifying its relationship to the global coordinate system of the view group; and each view device had a gxMapping that specified its location and the size of its pixels with regard to view group coordinates. THere was a single predefined view group which contained all on-screen view devices (and whose view ports effectively corresponded to on-screen windows); applications were free to create their own view groups for off-screen view devices and view ports.
- a gxTag allowed the attachment of arbitrary application-defined information to most of the above object types. Each tag had an OSType type code, but there could be multiple tags of the same type attached to the same object.
[edit] Shape types
GX shapes could be of various types:
- a straight line defined by its end points.
- a rectangle defined by its left, right, upper and lower bounds.
- a polygon defined by a sequence of vertex coordinates.
- a curve shape was a single quadratic Bézier curve defined by three control points.
- a path shape which was a sequence of quadratic Bézier curves. Each control point had an associated flag indicating whether it was "on-curve" or "off-curve". An on-curve point was a Bézier endpoint, while an off-curve point was a Bézier midpoint. If two successive off-curve points were encountered, then an implicit on-curve point was assumed to lie halfway between them. Two successive on-curve points defined a straight-line segment.
- a bitmap shape contained raster data in any of the supported pixel formats.
- a picture shape was a grouping of other shapes (possibly including recursive picture shapes), with the option of specifying additional transformations applying to the whole group.
- the various types of typographic shapes are described in the GX Typography section below.
- additional types which were perhaps not directly useful for drawing, but could be combined with other shapes in geometry calculations: the empty shape (drawing of which did nothing); the point shape consisting of a single point; and the full shape (of infinite extent).
[edit] Typography
The typography features of GX were integrated in the form of 3 types of gxShape:
- Text shapes were the simplest: these contained a single run of text rendered in a single font style.
- Glyph shapes were a way to use character shapes ("glyphs") as pure geometry, for instance as clipping paths.
- Layout shapes were the most elaborate. These could be divided into multiple runs with different font styles, even different language encodings and text directions. Thus, it was possible to embed a sequence of Arabic text, rendered right-to-left, within an outer sequence of left-to-right Roman text. Layout shapes unleashed the full power of contextual substitutions, kerning, variations and all the other capabilities of TrueType GX fonts. Their main restriction was that they were confined to a single line of text.
The GX API also provided hit-testing functions, so that for example if the user clicked on a layout shape in the middle of a ligature, or in the region between a change of text direction, GX itself would provide the smarts to determine which character position in the original text corresponded to the click.
[edit] TrueType GX
An important distinction in GX was drawn between a character and a glyph, a distinction also found in the Unicode Standard. A character was an abstract symbol from the character set of a writing system, such as the letter "f" in the writing systems of the Latin script. Whereas a glyph was a specific graphic shape from a particular font, whether the shape represented a single character or a set of characters. Thus, for example, the Hoefler Text font had glyphs to represent the letters "f" and "l". It also had another glyph to represent the ligature "fl", which could be automatically composed (instead of the individual glyphs) wherever the two abstract characters "f" and "l" occurred in sequence in the source text.
This distinction was important in that such contextual substitutions occurred at rendering time, without any changes to the source character string. Thus they had no impact on editing or searching of the text. PostScript Type 1 font files have one to one mapping only, and as ligatures are many to one mappings, they can not be inserted into the composition without changing the source character string, for instance, the ligature ffi is placed at the position of capital Y in Adobe font products, and "Adobe Offices" is composed by typing "Adobe O" <change font> "Y" <change font> "ces". In the layout the character string is broken, and in PDF made from streamed PostScript the characters f+f+i can only be reconstructed, if the name of the glyph follows a glyph naming list.
Contextual substitutions can be controlled by enabling or disabling the composition options of a TrueType GX font in WorldText on the Mac OS 9 CD or in TextEdit in Mac OS X. Fonts commonly have features called "common ligatures" (such as the "fl" example), "rare ligatures" (such as inscriptional ME and MD ligatures", "archaic non-terminal s" (for automatically substituting the letter "s" with the archaic form that looked more like an "f", except at the ends of words), and even choices between entirely separate sets of glyph designs, such as more and less ornate forms.
The rules for performing contextual substitutions are implemented as state machines built into the font, and interpreted by the LLM Line Layout Manager, the counterpart of the CMM Color Management Module for ColorSync services. Text management in the operating system allowed QuickDraw GX to accept character strings with any mix of writing systems and scripts, and compose the strings automatically, whether the encoding was Unicode 1.0 or 8 bit and 8/16 bit encodings.
Another interesting feature was font "variations," which were the GX equivalent of Adobe's "multiple master" fonts. Whereas Adobe's fonts required the user explicitly create an "instance" of the font by specifying values for the variation axes before he could use it, GX allowed the user to specify the font directly for a layout style, and then dynamically vary the axis values and immediately observe the effect on the layout of the text.
[edit] Developers
- Cary Clark was the architect and technical lead. He was an early member of Rocket Science and WebTV.
- Michael Fairman
- Keith McGreggor was the manager of the graphics group. He was the primary developer of the color architecture for QuickDraw GX.
- David Van Brink
- Robert Johnson was the resident mathematician for QuickDraw GX.
- Chris Yerba
- Oliver Steele
- Dave Good
- Pablo Fernicola
TrueType GX:
- Sampo Kaasila
- Mike Reed
- Arlo
[edit] External link
- QuickDraw GX — Apple's GX documentation "home page"
