diff -r 48780e181b38 -r 578be2adaf3e Symbian3/PDK/Source/GUID-667E7F90-D6C2-55CE-AE60-6C938072FB9C.dita
--- a/Symbian3/PDK/Source/GUID-667E7F90-D6C2-55CE-AE60-6C938072FB9C.dita Tue Jul 20 12:00:49 2010 +0100
+++ b/Symbian3/PDK/Source/GUID-667E7F90-D6C2-55CE-AE60-6C938072FB9C.dita Fri Aug 13 16:47:46 2010 +0100
@@ -9,81 +9,75 @@
-->
-Graphics
-and Drawing OverviewThis topic provides an introduction to drawing graphics to the
-screen.
+Graphics and Drawing OverviewThis topic provides an introduction to drawing graphics
+to the screen.
Variant: Both (ScreenPlay and non-ScreenPlay). Target
audience: Application developers.
-
Applications can draw to any RDrawableWindow —such as
-an RWindow —via a graphics device, of type CWsScreenDevice,
-and a graphics context, of type CWindowGc. These classes
-are derived from the GDI
-component classes CGraphicsDevice and CGraphicsContext,
-respectively. This means that general drawing functions can be used for drawing
-to windows, as well as to other graphics devices. The Window Server itself
-does not provide the facilities to draw graphics to a physical device. CWindowGc functions
-are not passed to the Window Server directly. Rather, they are stored in a
-buffer maintained by the Window Server Client API. This buffer is flushed
-to the Window Server only rarely. By this means the context switching involved
-in drawing is minimised, and system performance significantly enhanced.
+
Applications can draw to any RDrawableWindow —such
+as an RWindow —via a graphics device, of type CWsScreenDevice, and a graphics context, of type CWindowGc. These classes are derived from the GDI component classes CGraphicsDevice and CGraphicsContext, respectively. This means that general drawing functions can be
+used for drawing to windows, as well as to other graphics devices.
+The Window Server itself does not provide the facilities to draw graphics
+to a physical device. CWindowGc functions are not
+passed to the Window Server directly. Rather, they are stored in a
+buffer maintained by the Window Server Client API. This buffer is
+flushed to the Window Server only rarely. By this means the context
+switching involved in drawing is minimised, and system performance
+significantly enhanced.
CWsScreenDeviceminimized encapsulates the device-dependent
-aspects of graphics operations. Graphics functions are not carried out directly
-via a CWsScreenDevice, however, but via a graphics context
-with which it is associated. The graphics context class, CWindowGc,
-provides a rich set of drawing functions, including functions to draw lines,
-arcs, polygons, text and bitmaps.
-
A graphics context contains a collection of configurable parameters concerned
-with graphics, such as pen width, pen color, brush color. It is stored in
-the server, thus reducing the amount of information that has to be sent with
-each graphics call. The graphics call simply specifies the graphics context
-it wishes to use, and a single graphics context can be shared between multiple
-windows.
-
To draw to a graphics context it must be associated with a window. Typically
-a graphics context is created when a session is constructed, and that graphics
-context is shared between several windows in the application. When the window
-needs to use the graphics context it calls CWindowGc::Activate().
-If necessary it can change the graphics context's settings. CWindowGc::Deactivate() should
-be called first if the graphics context is currently active upon another window.
+aspects of graphics operations. Graphics functions are not carried
+out directly via a CWsScreenDevice, however, but
+via a graphics context with which it is associated. The graphics context
+class, CWindowGc, provides a rich set of drawing
+functions, including functions to draw lines, arcs, polygons, text
+and bitmaps.
+
A graphics context contains a collection of configurable parameters
+concerned with graphics, such as pen width, pen color, brush color.
+It is stored in the server, thus reducing the amount of information
+that has to be sent with each graphics call. The graphics call simply
+specifies the graphics context it wishes to use, and a single graphics
+context can be shared between multiple windows.
+
To draw to a graphics context it must be associated with a window.
+Typically a graphics context is created when a session is constructed,
+and that graphics context is shared between several windows in the
+application. When the window needs to use the graphics context it
+calls CWindowGc::Activate(). If necessary it can
+change the graphics context's settings. CWindowGc::Deactivate() should be called first if the graphics context is currently active
+upon another window.
Several optimizations are used by the Window Server to obtain high-performance
graphics:
-
Each window is associated
-with an RWsSession which is in turn associated with a client-side
-buffer. Instead of implementing graphics operations by a direct client-server
-call, which involves expensive context switching, all graphics operations
-are stored as opcodes in the buffer, and the buffer is only flushed in certain
-circumstances.
-
The CFbsBitmap class
-allows a bitmap to be shared between all threads in the system, including
-the client and the Window Server. This sharing is mediated by the Font
-and Bitmap server. The CWsBitmap class eliminates
-further context switches by taking ownership of the handle of the bitmap.
-Applications can use this class to more efficiently open, blit-to-screen,
-and close a series of bitmaps. Use functions that take a CWsBitmap in
-preference to those that take a CFbsBitmap, because they
-are faster.
-
A single graphics context
-may be used for drawing to many windows—it is not necessary to have one per
-window. The Activate() function associates a CWindowGc with
-a particular window.
-
Provided drawing operations
-to an RWindow are performed as redraw
-drawing, the Window Server stores the sequence of drawing commands
-that represent the window contents in redraw stores. Then when the Window
-Server needs to repaint the window (because, for example, a dialog box popped
-up over it and has now closed) it simply replays the sequence of stored commands,
-rather than sending a redraw request to the client. This minimizes the number
-of client-server transactions and means that windows are repainted as soon
-as the Window Server detects that they are needed.
This means that
-all CWindowGc drawing should now be redraw drawing, which
-means that it takes place between RWindow::BeginRedraw() and RWindow::EndRedraw() calls.
-If you use the CCoeControl::DrawNow() and CCoeControl::DrawDeferred() methods,
-the UI Control Framework (CONE) takes care of this for you. See Redraw
-Drawing for more information.
+
Each window
+is associated with an RWsSession which is in turn
+associated with a client-side buffer. Instead of implementing graphics
+operations by a direct client-server call, which involves expensive
+context switching, all graphics operations are stored as opcodes in
+the buffer, and the buffer is only flushed in certain circumstances.
+
The CFbsBitmap class allows a bitmap to be shared between all
+threads in the system, including the client and the Window Server.
+This sharing is mediated by the Font and Bitmap server. The CWsBitmap class eliminates further context
+switches by taking ownership of the handle of the bitmap. Applications
+can use this class to more efficiently open, blit-to-screen, and close
+a series of bitmaps. Use functions that take a CWsBitmap in preference to those that take a CFbsBitmap,
+because they are faster.
+
A single graphics
+context may be used for drawing to many windows—it is not necessary
+to have one per window. The Activate() function associates
+a CWindowGc with a particular window.
+
Provided drawing
+operations to an RWindow are performed as redraw drawing, the Window Server stores the sequence of drawing commands that
+represent the window contents in redraw stores. Then when the Window
+Server needs to repaint the window (because, for example, a dialog
+box popped up over it and has now closed) it simply replays the sequence
+of stored commands, rather than sending a redraw request to the client.
+This minimizes the number of client-server transactions and means
+that windows are repainted as soon as the Window Server detects that
+they are needed.
This means that all CWindowGc drawing should now be redraw drawing, which means that it takes
+place between RWindow::BeginRedraw() and RWindow::EndRedraw() calls. If you use the CCoeControl::DrawNow() and CCoeControl::DrawDeferred() methods, the
+UI Control Framework (CONE) takes care of this for you. See Redraw Drawing for more information.
Graphics
and Drawing
-The UI Control
-Framework (CONE)
+The UI Control Framework
+(CONE)
\ No newline at end of file