Introduction of VC double buffering drawing technology

Introduction of VC double buffering drawing technology

Double-buffered drawing, which is a basic graphic image drawing technique. First, it creates an object in memory that is consistent with the screen drawing area, then draws the graphic to the object in memory and finally copies and displays the graphic data on the object to the screen at once. This technology can greatly improve the speed of the drawing, reduce the problem of stalling and splash screen.

Why should we use double buffering technology to draw?
In application development, when the amount of image information data is large, the drawing may take a few seconds or longer, and the application may become stuck. In addition, if the form in response to the WM_PAINT message, but also complex graphics processing, the form will be redrawn due to frequent refresh caused by flicker phenomenon, and the use of double buffering technology can effectively solve the above problems.

Flashing issues:
When the form is refreshed, there is always a process to erase the original image OnEraseBkgnd, which fills the form plot area with the background color, and then calls the new drawing code to redraw, so that the contrast of the image color is caused by a wipe. When WM_PAINT's response is frequent, the contrast is becoming more pronounced. So we saw a flicker.
If you just remove the fill from the background color, it's true that no matter how you redraw the graphic, it won't flash. But in that case, the form screen tends to become messy. Because each time the image is not removed from the original image, resulting in a residual image, superimposed new graphics. So simply banning background repainting is not enough, and we're going to redraw it. Drawing functions can use BITBLT, which supports the copying of graphics blocks and is very fast.

double-buffered drawing implementation:
First, the graphics to be displayed in memory first, and then one at a time to overlay the graphics in memory to the screen at a point (the process is very fast, because it is a very complete memory copy), so that the background color erase the interface and then map to the screen will not blink.
Steps:

1. Create a buffer in memory that is consistent with the canvas;
2. drawing in buffer;
3. Copies the buffer bitmap to the current canvas and displays it on the screen;
4. Frees the memory buffer.

Flowchart:

Code implementation:
Here in VC + + development Platform using MFC development, generally in the OnDraw and OnPaint functions for image rendering.
First screen background refresh, background refresh is actually in response to the WM_ERASEBKGND message, we just have to change the ONERASEBKGND function return value to true on the line.

//' direct drawing ', here redrawing will appear in the phenomenon of KakavoidCdoublebufferdlg::D rawitem(CDC*PDC) {assert_valid (PDC);       CRect rcclient; Pdc -Getclipbox (rcclient); CPen Pen (Ps_solid,1, RGB (178,178,178)); CPen*Poldpen= NULL; Poldpen=Pdc -SelectObject (&pen); Pdc -Ellipse (rcclient); for (Int J=0; j< +; j++) {PDC -MoveTo (0,0); Pdc -LineTo (rcclient.Width (), rcclient.Height ()); Pdc -MoveTo (rcclient.Width (),0); Pdc -LineTo (0, rcclient.Height ()); }//Cleanup after drawing is completePdc -SelectObject (Poldpen); }//' double-buffered drawing 'voidCdoublebufferdlg::D rawitemwithdoublebuffer(CDC*PDC) {assert_valid (PDC);    CRect rcclient; Pdc -Getclipbox (rcclient);//define a memory display device context objectCDC MEMDC;//Define a GDI bitmap objectCBitmap Membitmap;//Create a Memory device context (DC) that is compatible with the specified device (this is the screen)Memdc.CreateCompatibleDC (PDC);//Create a bitmap compatible with the screen display, the size of the bitmap can be selected window client area sizeMembitmap.CreateCompatibleBitmap (PDC, rcclient.Width (), rcclient.Height ());//The bitmap object is selected into the memory display device context, only selected for drawingCBitmap*Poldbit=Memdc.SelectObject (&MEMBITMAP);//First clear the bitmap with a white background color, otherwise it will be black. Memdc.Fillsolidrect (0,0, rcclient.Width (), rcclient.Height (), RGB (255,255,255));//define brush, color is grayCPen Pen (Ps_solid,1, RGB (178,178,178)); CPen*Poldpen= NULL;//Select the Brush object into the specified device contextPoldpen=Memdc.SelectObject (&pen);//-----------------------------------------drawing Operations    //need to be placed before the BitBlt function    //Draw EllipseMemdc.Ellipse (rcclient);//Draw diagonal, more cycles, no double buffering will stutterfor (int i=0; I< +; I++) {MEMDC.MoveTo (0,0); Memdc.LineTo (rcclient.Width (), rcclient.Height ()); Memdc.MoveTo (rcclient.Width (),0); Memdc.LineTo (0, rcclient.Height ()); }//-----------------------------------------drawing Operations    //Copy the in-memory diagram to the screen for displayPdc -BITBLT (0,0, rcclient.Width (), rcclient.Height (),&MEMDC,0,0, srccopy);//Cleanup after drawing is completeMemdc.SelectObject (Poldpen); Memdc.SelectObject (Poldbit);//Use GetDC () with ReleaseDC    :: ReleaseDC(This -M_hwnd, MEMDC); Poldpen -DeleteObject (); Membitmap.DeleteObject (); }

:

Knowledge Concept (excerpt from Baidu Encyclopedia):
GDI
Under the Windows operating system, the vast majority of applications with graphical interface can not be separated from GDI, we use the many functions provided by GDI to easily output graphics, text and other operations on the screen, printers and other output devices. So what exactly are we GDI?
GDI is the abbreviation for the graphics device interface, meaning the interface of the graphical devices, whose main task is to exchange information between the system and the drawing program, and to process the graphics output of all Windows programs. Its appearance makes the programmer need not care about the hardware device and the device drive, can transform the output of the application into the output of the hardware device, realizes the isolation of the program developer and the hardware device, greatly facilitates the development work. GDI has the following features:

1. The program is not allowed to access the physical display hardware directly, through the abstract interface called "Device Environment (DC)" To access the display hardware indirectly;
2. When the program needs to communicate with the display hardware (monitor, printer, etc.), the device environment associated with the specific window must be obtained first;
3. The user does not care about the specific physical device type;
4. The data structure of the Windows Reference device environment is finished with the output.

The above equipment environment is our DC (device context).

DC (device context)
In a Windows environment, the output of each program must be limited to its own window.
GDI uses a simple mechanism to ensure that the programs that draw in Windows follow this rule. This mechanism is the device Description table (DC); When a Windows program paints on a screen, printer, or other device, it does not output pixels directly to the device, but instead draws the diagram to a "display plane" in the logical sense represented by the device description table. A Device description table is a data structure that is deep in Windows and contains all the description fields that GDI needs about the display plane, including connected physical devices and a variety of state information.
A Device description table, also known as a device context, or a device environment, is a graphical representation (data) structure that defines a set of graphical objects (brushes, and so on) and their properties, affecting the output. Windows provides a Device description table for interacting between applications and physical devices, providing platform-agnostic application design.
A Device description table is a data structure that includes information about the drawing properties of a device, such as a display and a printer. All drawing operations are performed through the device description table. The device description table differs from most WIN32 structures in that the application cannot directly access the device Description table and can only access the structure indirectly through a handle to the device description table by a variety of related API functions.
The Device description table is always associated with a system hardware device. For example, the screen Device description table is related to the display device, the printer Device description table is related to the printing device and so on.
Screen device Description table, generally we simply call it a device description table. It has a certain correspondence with the display device, which, under the Windows GDI interface, is always related to a window or to a display area on the window. Usually the window device description table, generally refers to the window of the client area, not including the title bar, the menu bar occupies the area, and for the entire window, its Device Description table strictly speaking should be called the Window Device description table, it contains the full display area of the window. The method of operation is exactly the same, the difference is only the scope of operation is different.
Once the Windows window is created, it automatically produces the corresponding Device description table data structure, which allows the user to implement GDI Operations on the window display area, such as scribing, writing text, drawing bitmaps, filling, etc., and all of these operations are done through the device descriptor table handle.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Introduction of VC double buffering drawing technology