NeXTSTEP used Display PostScript (DPS) for the display. This made the platform very attractive for desktop publishing, since the output to the display and printer were the same. PostScript is a very complex language. It is Turing-complete, meaning that it can implement any algorithm. This was convenient for printing, since it allowed complex programs to be sent to the printer and generate complex documents. It is less convenient for on-screen drawing. If you send a PostScript program to the printer that infinite loops, you just turn the printer off and on again and resubmit your jobs. If you do the same with a display server, you have a problem. A well-designed Display PostScript implementation can kill widgets that run for too long, but defining “too long” is nontrivial.
Most users didn’t use much of the power of DPS. They used bezier curves and simple drawing commands, but wrote all of the control structures in C or Objective-C. This removed one of the main advantages of a DPS-like environment. Sun produced a similar PostScript-based windowing system called NeWS, which competed with the X Windowing System in the early days of graphical UNIX. The main advantage of NeWS over X was that graphical objects were written in PostScript and sent over the network to the display. When you clicked on a button on an X GUI, it sent a “mouse clicked” event to the remote machine, which then sent X commands back to handle updating the UI. With NeWS, the PostScript UI processed the event, drew the pressed button image, and sent a “button pressed” event to the remote machine. This enabled much lower-latency remote display. NeXT, however, never pushed remote display for DPS and so this capability was not exploited. When it came time to produce OS X, Apple investigated using X11 instead of DPS, since it was standard on other UNIX-like platforms at the time (and still is).
They found that it lacked a number of features they needed, such as good support for antialiased fonts, color calibration, and compositing. DPS didn’t support all of these things either, so Apple wrote a new system. Since no one was using the DPS flow control structures, these were the first to go. Adobe had already created a PostScript-like language without flow control: Portable Document Format (PDF). The new windowing system adopted the PDF drawing model and integrated compositing support from the start and is sometimes referred to as Display PDF. Earlier windowing systems—X11, DPS, NeWS, and the Windows GDI—were all created in an era when RAM was very expensive. Buffering every single window on a display could easily take tens of megabytes of memory. The framebuffer alone for the original NeXT workstations was almost 2MB (1120×832 in 16-bit color), and buffers for overlapping windows could easily have filled the 12MB of RAM the color version included. When OS X was introduced, the target machine had at least 64MB of RAM, 16MB of video RAM, and a similar sized display. This made buffering everything a lot more attractive, since the cost was relatively small and the benefit was reducing the CPU used for redrawing and eliminating tearing.
The first versions of OS X were relatively slow for large graphics updates, since all of the compositing was performed on the CPU. Later versions offloaded this to the GPU that could perform composting operations much faster. The updated version was called Quartz Extreme. With 10.4, Apple attempted to offload even more to the GPU. Somewhat ironically, the most expensive graphical operation on OS X is rendering text.
Quartz GL, formerly Quartz 2D Extreme, accelerated this by rendering each font glyph as an antialiased outline to a texture and then drawing them by compositing these together.
This was a lot faster than drawing the bezier curves of each glyph for every character. When it was introduced, Quartz 2D Extreme was less reliable than its predecessor and so was not enabled by default. It can still be enabled by the end user with the Quartz Debug utility, which is included with the developer tools bundle. It is often said that Quartz uses OpenGL. This is not true. Quartz may use the 3D hardware, but it does so via its own interface. Both OpenGL and Quartz are built on top of the 3D hardware drivers. Quartz windows may contain OpenGL contexts, allowing OpenGL to be used on OS X. The deformations on Windows and compositing operations are all implemented directly by Quartz and the window server. The programmatic interface to the Quartz is called Core Graphics. This provides low-level drawing functions following the PDF model. You can use Core Graphics to draw antialiased bezier curves, filled shapes, and composited bitmaps. These functions are also wrapped by AppKit APIs. The iPhone, which does not use AppKit, does have an implementation of Core Graphics, so drawing code using these APIs will work on both systems.
Source of Information : Addison Wesley - Cocoa Programming Developers Handbook (December 2009)
Most users didn’t use much of the power of DPS. They used bezier curves and simple drawing commands, but wrote all of the control structures in C or Objective-C. This removed one of the main advantages of a DPS-like environment. Sun produced a similar PostScript-based windowing system called NeWS, which competed with the X Windowing System in the early days of graphical UNIX. The main advantage of NeWS over X was that graphical objects were written in PostScript and sent over the network to the display. When you clicked on a button on an X GUI, it sent a “mouse clicked” event to the remote machine, which then sent X commands back to handle updating the UI. With NeWS, the PostScript UI processed the event, drew the pressed button image, and sent a “button pressed” event to the remote machine. This enabled much lower-latency remote display. NeXT, however, never pushed remote display for DPS and so this capability was not exploited. When it came time to produce OS X, Apple investigated using X11 instead of DPS, since it was standard on other UNIX-like platforms at the time (and still is).
They found that it lacked a number of features they needed, such as good support for antialiased fonts, color calibration, and compositing. DPS didn’t support all of these things either, so Apple wrote a new system. Since no one was using the DPS flow control structures, these were the first to go. Adobe had already created a PostScript-like language without flow control: Portable Document Format (PDF). The new windowing system adopted the PDF drawing model and integrated compositing support from the start and is sometimes referred to as Display PDF. Earlier windowing systems—X11, DPS, NeWS, and the Windows GDI—were all created in an era when RAM was very expensive. Buffering every single window on a display could easily take tens of megabytes of memory. The framebuffer alone for the original NeXT workstations was almost 2MB (1120×832 in 16-bit color), and buffers for overlapping windows could easily have filled the 12MB of RAM the color version included. When OS X was introduced, the target machine had at least 64MB of RAM, 16MB of video RAM, and a similar sized display. This made buffering everything a lot more attractive, since the cost was relatively small and the benefit was reducing the CPU used for redrawing and eliminating tearing.
The first versions of OS X were relatively slow for large graphics updates, since all of the compositing was performed on the CPU. Later versions offloaded this to the GPU that could perform composting operations much faster. The updated version was called Quartz Extreme. With 10.4, Apple attempted to offload even more to the GPU. Somewhat ironically, the most expensive graphical operation on OS X is rendering text.
Quartz GL, formerly Quartz 2D Extreme, accelerated this by rendering each font glyph as an antialiased outline to a texture and then drawing them by compositing these together.
This was a lot faster than drawing the bezier curves of each glyph for every character. When it was introduced, Quartz 2D Extreme was less reliable than its predecessor and so was not enabled by default. It can still be enabled by the end user with the Quartz Debug utility, which is included with the developer tools bundle. It is often said that Quartz uses OpenGL. This is not true. Quartz may use the 3D hardware, but it does so via its own interface. Both OpenGL and Quartz are built on top of the 3D hardware drivers. Quartz windows may contain OpenGL contexts, allowing OpenGL to be used on OS X. The deformations on Windows and compositing operations are all implemented directly by Quartz and the window server. The programmatic interface to the Quartz is called Core Graphics. This provides low-level drawing functions following the PDF model. You can use Core Graphics to draw antialiased bezier curves, filled shapes, and composited bitmaps. These functions are also wrapped by AppKit APIs. The iPhone, which does not use AppKit, does have an implementation of Core Graphics, so drawing code using these APIs will work on both systems.
Source of Information : Addison Wesley - Cocoa Programming Developers Handbook (December 2009)
|
|
0 comments
Post a Comment