ISO Drawing

ISO provide 2 drawing path:

  use native drawing technologies include Core Graphic and UIKit Framework, support 2D Drawing.

  use Open GL ES.  for 2D and 3D

in this articl I just gather the native drawing technologies.

The iOS native graphics system combines three major technologies: UIKit, Core Graphics, and Core Animation.
UIKit provides views and some high-level drawing functionality within those views, Core Graphics provides
additional (lower-level) drawing support within UIKit views, and Core Animation provides the ability to apply

transformations and animation to UIKit views. Core Animation is also responsible for view compositing.

The UIKit and Core Graphics have many complementary graphics capabilities that encompass graphics contexts,
Bézier paths, images, bitmaps, transparency layers, colors, fonts, PDF content, and drawing rectangles and
clipping areas. In addition, Core Graphics has functions related to line attributes, color spaces, pattern colors,
gradients, shadings, and image masks. The Core Animation framework enables you to create fluid animations
by manipulating and displaying content created with other technologies.

Apps Can Draw Into Offscreen Bitmaps or PDFs
It is often useful for an app to draw content offscreen:
● Offscreen bitmap contexts are often used when scaling down photographs for upload, rendering content
into an image file for storage purposes, or using Core Graphics to generate complex images for display.
● Offscreen PDF contexts are often used when drawing user-generated content for printing purposes.
After you create an offscreen context, you can draw into it just as you would draw within the drawRect:
method of a custom view.

offscreen context,  UIKit drawRect 提供的current-screen context

Each of the drawing frameworks of iOS establishes a default coordinate system based on the current graphics
context. In iOS, there are two main types of coordinate systems:

● An upper-left-origin coordinate system (ULO), in which the origin of drawing operations is at the upper-left
corner of the drawing area, with positive values extending downward and to the right. The default
coordinate system used by the UIKit and Core Animation frameworks is ULO-based.

● A lower-left-origin coordinate system (LLO), in which the origin of drawing operations is at the lower-left
corner of the drawing area, with positive values extending upward and to the right. The default coordinate
system used by Core Graphics framework is LLO-based.

Before calling your view’s drawRect: method, UIKit establishes the default coordinate system for drawing to
the screen by making a graphics context available for drawing operations. Within a view’s drawRect: method,
an app can set graphics-state parameters (such as fill color) and draw to the current graphics context without
needing to refer to the graphics context explicitly. This implicit graphics context establishes a ULO default
coordinate system.

Points Versus Pixels
In iOS there is a distinction between the coordinates you specify in your drawing code and the pixels of the
underlying device. When using native drawing technologies such as Quartz, UIKit, and Core Animation, the
drawing coordinate space and the view’s coordinate space are both logical coordinate spaces, with distances
measured in points. These logical coordinate systems are decoupled from the device coordinate space used
by the system frameworks to manage the pixels onscreen.
The system automatically maps points in the view’s coordinate space to pixels in the device coordinate space,
but this mapping is not always one-to-one. This behavior leads to an important fact that you should always
remember:
One point does not necessarily correspond to one physical pixel.
The purpose of using points (and the logical coordinate system) is to provide a consistent size of output that
is device independent. For most purposes, the actual size of a point is irrelevant. The goal of points is to provide
a relatively consistent scale that you can use in your code to specify the size and position of views and rendered
content. How points are actually mapped to pixels is a detail that is handled by the system frameworks. For
example, on a device with a high-resolution screen, a line that is one point wide may actually result in a line
that is two physical pixels wide. The result is that if you draw the same content on two similar devices, with
only one of them having a high-resolution screen, the content appears to be about the same size on both
devices.
In iOS, the UIScreen, UIView, UIImage, and CALayer classes provide properties to obtain (and, in some
cases, set) a scale factor that describes the relationship between points and pixels for that particular object.
For example, every UIKit view has a contentScaleFactor property. On a standard-resolution screen, the
scale factor is typically 1.0. On a high-resolution screen, the scale factor is typically 2.0. In the future, other scale
factors may also be possible. (In iOS prior to version 4, you should assume a scale factor of 1.0.)

Native drawing technologies, such as Core Graphics, take the current scale factor into account for you. For
example, if one of your views implements a drawRect: method, UIKit automatically sets the scale factor for
that view to the screen’s scale factor. In addition, UIKit automatically modifies the current transformation matrix
of any graphics contexts used during drawing to take into account the view’s scale factor. Thus, any content
you draw in your drawRect: method is scaled appropriately for the underlying device’s screen.
Because of this automatic mapping, when writing drawing code, pixels usually don’t matter. However, there
are times when you might need to change your app’s drawing behavior depending on how points are mapped
to pixels—to download higher-resolution images on devices with high-resolution screens or to avoid scaling
artifacts when drawing on a low-resolution screen, for example.

Color and Color Spaces
iOS supports the full range of color spaces available in Quartz; however, most apps should need only the RGB
color space. Because iOS is designed to run on embedded hardware and display graphics onscreen, the RGB
color space is the most appropriate one to use.
The UIColor object provides convenience methods for specifying color values using RGB, HSB, and grayscale
values. When creating colors in this way, you never need to specify the color space. It is determined for you
automatically by the UIColor object.
You can also use the CGContextSetRGBStrokeColor and CGContextSetRGBFillColor functions in the
Core Graphics framework to create and set colors. Although the Core Graphics framework includes support for
creating colors using other color spaces, and for creating custom color spaces, using those colors in your
drawing code is not recommended. Your drawing code should always use RGB colors.

Quartz is the general name for the native drawing technology in iOS. The Core Graphics framework is at the
heart of Quartz, and is the primary interface you use for drawing content. This framework provides data types
and functions for manipulating the following:
● Graphics contexts
● Paths
● Images and bitmaps
● Transparency layers
● Colors, pattern colors, and color spaces
● Gradients and shadings
● Fonts
● PDF content

UIKit builds on the basic features of Quartz by providing a focused set of classes for graphics-related operations.
The UIKit graphics classes are not intended as a comprehensive set of drawing tools—Core Graphics already
provides that. Instead, they provide drawing support for other UIKit classes. UIKit support includes the following
classes and functions:
● UIImage, which implements an immutable class for displaying images
● UIColor, which provides basic support for device colors
● UIFont, which provides font information for classes that need it
● UIScreen, which provides basic information about the screen
● UIBezierPath, which enables your app to draw lines, arcs, ovals, and other shapes.
● Functions for generating a JPEG or PNG representation of a UIImage object
● Functions for drawing to a bitmap graphics context
● Functions for generating PDF data by drawing to a PDF graphics context
● Functions for drawing rectangles and clipping the drawing area
● Functions for changing and getting the current graphics context

To flip a object drawn to a Core Graphics context so that it appears correctly when displayed in a UIKit view,
you must modify the CTM in two steps. You translate the origin to the upper-left corner of the drawing area,
and then you apply a scale translation, modifying the y-coordinate by -1. The code for doing this looks similar
to the following:

CGContextSaveGState(graphicsContext);
CGContextTranslateCTM(graphicsContext, 0.0, imageHeight);
CGContextScaleCTM(graphicsContext, 1.0, -1.0);
CGContextDrawImage(graphicsContext, image, CGRectMake(0, 0, imageWidth,
imageHeight));
CGContextRestoreGState(graphicsContext);