Symbian screen dual buffering and DSA

 

Refer to the previous article on the Internet to reorganize the knowledge of Dual-buffering and DSA on the screen!

(1) graphic settings and graphic Context

The application must use a graphical device and graphical context to draw a graph.

A graphical device is a drawing object (such as a screen or printer). A graphical device context provides a device abstraction mechanism to completely block a specific graphic device, when using these graphics devices, applications only need to interact with these abstract graphics devices without considering their specific devices.

The graphic context is a collection of tools required for the painting platform and painting. It also includes the size, direction, color of the platform and all the accessories that can achieve the painting imagination.

The following figure shows the graphic devices used in Symbian and their functions. They are the basis for painting.

Graphics Devices	Description
Cgraphicsdevice	Basic Category of graphics Devices
Cbitmapdevice	Basic class of bitmap graphics Devices
Cfbsdevice	Graph device base class using the font bitmap Server
Cprinterdevice	Device base class with printing function
Cwsscreendevice	Use the screen device of the window Server
Cfbsbitmapdevice	Specific implementation of devices using the font bitmap Server
Cfbsscreendevice	Direct screen access (DSA) without passing through the window Server

The inheritance relationships of these devices are as follows:

 

CwindowsgcFor screen painting, cfbsbitgc for memory painting!

(2) Double Buffering

Generally, the application uses the cwsscreendevice Graphics Device to describe on the screen, which is associated with the cwindowgc graphics context. Cone provides a cwindowgc instance as the standard graphical context of the Drawing Control. It is created by ccoeenv and can be accessed using the ccoecontrols: systemgc () method. The cwindowgc method is used to buffer the client window Server Buffer.

Void cexamplecontrol: Draw (const trect &/* arect */) const { 　// Get the system graphics context Cwindowgc & GC = systemgc (); 　// Set drawing settings GC. setbrushstyle (cgraphicscontext: esolidbrush ); GC. setbrushcolor (krgbred ); 　// Draw GC. drawline (tpoint (10, 10), tpoint (30, 10 )); }

Drawnow () forces the control to re-draw itself immediately, while drawdeferred () causes a re-draw event to use low-priority operations!

If a game's graphics are composed of multiple motion objects that need to be updated frequently, the client buffer of the window server may be filled and may overflow when all objects are updated, the screen may flash. If a view is still being updated, it may flash or have other undesirable effects. The solution to these problems is dual buffering. The image is first painted on an off-screen bitmap and then painted on the screen as a single window server. Especially for games that redraw screens several times in one second, using off-screen bitmaps can improve their performance.

 

An out-of-screen bitmap can be created using bitmap graphics context and graphics equipment class: cfbsbitgc and cfbsbitmapdevice. They are created and used using other context and device classes. For extra performance, the bitmap itself should be a cwsbitmap bitmap. After the screen bitmap is updated, it can be painted in the window using the normal method of the window server.

　　When an application draws a bitmap in a window, it is converted to the same display mode as the window. This is a very time-consuming operation, which may actually reduce the plotting speed. Therefore, the game that uses bitmaps for animation should complete the conversion before the animation starts.The conversion can be performed by using an off-screen bitmap, as shown in the following example:

Cfbsbitmap * cexamplecontrol: loadandconvertbitmapl (const tdesc & afilename, tint abitmapid) { // Load the bitmap Cfbsbitmap * originalbitmap = new (eleave) cfbsbitmap (); Cleanupstack: pushl (originalbitmap ); User: leaveiferror (originalbitmap-> load (afilename, abitmapid, efalse )); // Create a new bitmap, Graphics Device and context Cfbsbitmap * newbitmap = new (eleave) cfbsbitmap (); Cleanupstack: pushl (newbitmap ); Newbitmap-> Create (originalbitmap-> sizeinpixels (), window ()-> displaymode ()); Cfbsbitmapdevice * graphicsdevice = cfbsbitmapdevice: newl (newbitmap ); Cleanupstack: pushl (graphicsdevice ); Cfbsbitgc * graphicscontext; User: leaveiferror (graphicsdevice-> createcontext (graphicscontext )); Tpoint zero (0, 0 ); // Bmap the loaded bitmap to the new bitmap Graphicscontext-> bitblt (zero, originalbitmap ); Cleanupstack: Pop (3 ); Delete graphicscontext; Delete graphicsdevice; Delete originalbitmap; Return newbitmap; }

The example uses a file name and a bitmap ID as the parameter, and loads the corresponding bitmap from an MBM file. If a game has many bitmaps that should be converted, it should be converted in the game or Level Initialization phase, so the user will not see this operation.

(2) Direct screen access (DSA)

Using a window server to draw images on the screen requires a context conversion, which slows down the painting speed. To bypass the window server, you can directly access the screen without tedious context conversion. This is called direct screen access.

There are two methods in Symbian OS to draw images directly on the screen:

　　① CfbsscreendeviceIsScreen driver scdv. dll. After creating a cfbsbitgc image context, it can be used like any other graphics device. However, you can draw images directly on the screen without using a window server.

②Another way to draw images directly on the screen isQuery the screen memory address from the system,This can be achieved using the usersrv class:

Tpckgbuf <tscreeninfov01> infopckg; Tscreeninfov01 & screeninfo = infopckg (); Usersvr: screeninfo (infopckg ); Tuint16 * screenmemory = screeninfo. iscreenaddress + 16;

The screen memory has a 32-byte header.

Even if writing data in the screen memory is a little faster than cfbsscreendevice, the function may vary depending on the hardware and the driver of the screen.In some Symbian OS-based terminals, the screen is automatically updated from the screen memory when the memory changes, while in other terminals, it needs to be explicitly activated.. The screen memory address is only valid for the target hardware. Therefore, the plotting code must be divided into two parts: hardware and simulator. In the simulator environment, you can draw an out-of-screen bitmap instead of the screen memory, and then use the normal window server to draw a method block to transfer it to the screen.The environment can be detected by using the _ wins _ definition.

# Ifdef _ wins _ // emulator Environment
// Draw to an off-screen bitmap
# Else // hardware environment
// Draw directly to the screen memory
# Endif

　　One common problem between the two direct plotting methods is that the window server does not understand the plotting.Therefore, it cannot notify the application whether another window or window group exists. Even if an application gets an event when it loses focus, it cannot stop Directly Plotting because it is too fast and the screen content may be messed up. This may happen when a phone call comes in during a game.

The latest GT 6.1 version provides an Application Programming Interface for direct plotting, which can solve the problems mentioned above.

This application programming interface consists of two classes:A mdirectscreenaccess class that provides callback methods for applications, and a cdirectscreenaccess class that processes communications with window servers. The following code describes how the cdirectscreenaccess instance is constructed and how the direct drawing support is activated.

Idrawer = cdirectscreenaccess: newl (ieikonenv-> wssession (), * ieikonenv-> screendevice (), window (), * This );
Ieikonenv-> wssession (). Flush ();
Idrawer-> startl ();
Idrawer-> screendevice ()-> setautoupdate (etrue );

The newl method of cdirectscreenaccess obtainsWindow Server session,Cone graphics Devices,Application WindowAndA pointer to the mdirectedscreenaccess export classAs a parameter. Before cdirectscreenaccess: startl is called to activate direct plotting, the client window Server Buffer should overflow.In order to automatically update the screen, the setautoupdate method of the screen device must use the etrue parameter. Otherwise, the GC draw command will not be immediately displayed in the simulator, but will not be displayed in the next flush window server.When direct plotting supports activation, cdirectscreenaccess generates a cfbsbitgc graphical context that can be used by applications to draw images on the screen.

Idrawer-> GC ()-> bitblt (tpoint (0, 0), ibitmap );

When another window appears in the application window, cdirectscreenaccess obtains an event from the window server to interrupt the profiling.Cdirectscreenaccess then calls the abortnow method of the derived class of mdirectscreenaccess. This method must be reloaded by the application to interrupt plotting.To prevent screen clutter, the window server does not draw overlapping windows until the trace interruption event is handled.