In the Mac OS X architecture, however, the screen resolution is almost irrelevant as far as memory usage is concerned. It's easy to calculate the video memory needed for display of a given size using this more traditional architecture: two frame buffers the same size and depth as the screen itself (e.g. In this way, no one ever sees drawing "as it happens." Applications draw into the off-screen frame buffer, and the video card swaps the two when the drawing is done. To enable smoother drawing, it is possible to use two frame buffers: one on-screen and one off-screen. This frame buffer is usually stored in dedicated video memory on the video card, rather than in main memory. Each application draws into a single shared "frame buffer" that is the same size as the screen itself (e.g. Instead, applications are asked to redraw any newly revealed portion of their windows. In more traditional architectures, bitmaps are not retained for every window on the screen. Worse, it scales linearly with the number and size of windows on the screen. As we've seen in earlier articles, the amount of memory used by the window server for retaining window bitmaps quickly becomes substantial. There are at least two performance problems with this architecture. So, in a nutshell: applications issue drawing commands using one of the various drawing APIs the drawing APIs produce a bitmaps based on these (possibly vector-based) drawing commands the window server retains the resulting bitmaps and composites them into a pleasing, cohesive final image on the screen. cursor movement, mouse clicks, typing) to the appropriate applications, and manages the cursor. The window server also routes events (e.g. The bitmap serves as a buffer, allowing the window server to "remember" an application's window contents and to recomposite it without the application's involvement. Each window is represented as a bitmap that includes both translucency (alpha channel) and anti-aliasing information. composites and recomposites each pixel of an application's window as the window is drawn, redrawn, covered, and uncovered. The window server produces the final screen image by compositing all of the visible window bitmaps with each other according to their position and layering. Each window has an associated bitmap (created by the application that owns the window using one of the drawing APIs). The Quartz Compositor (formerly " Core Graphics Services") is implemented as a single "window server" process that is responsible for managing all on-screen windows. QuickDraw actually uses some Quartz 2D APIs in its back end, but QuickTime and OpenGL do most of their own drawing.Īll of the bitmapped data produced by Quartz 2D, QuickDraw, QuickTime, and OpenGL is passed to the Quartz Compositor for eventual display on the screen. Quartz 2D has several "sibling" APIs that also produce bitmapped data for screen display: QuickDraw, QuickTime, and OpenGL. Quartz 2D accepts input from a variety of sources and can produce output in several different formats, including PDF, PostScript, and of course bitmaps suitable for screen display. As a result, a shape can be efficiently defined as a series of paths and attributes rather than as a bitmap. You do not need to specify the attributes of individual pixels. APIs allow you to create text and images by specifying a sequence of commands and mathematical statements that place lines, shapes, color, shading, translucency, and other graphical attributes in two-dimensional space. The Mac OS X System Overview describes its capabilities succinctly: Quartz 2D (formerly " Core Graphics Rendering") is a vector-based 2D drawing library. It has two parts: Quartz 2D and the Quartz Compositor. Quartz is an umbrella term that describes the core technologies used by Mac OS X to render images.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |