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