Introduction to VC double buffer Drawing Technology and vc buffer drawing

Introduction to VC double buffer Drawing Technology and vc buffer drawing

Double-buffered plotting is a basic graphic image plotting technology. First, it creates an object in the memory that is consistent with the screen drawing area, and then draws the image to this object in the memory, finally, copy and display the graphic data on this object to the screen at a time. This technology can greatly increase the drawing speed and reduce choppy and pop-screen problems.

Tip:
Check it out! 1.
Why do we need to use double buffering technology for plotting?
In application development, when the amount of image information is large, drawing may take several seconds or even longer. In this case, the application may be stuck. In addition, if the form must perform complex graphic processing when responding to the WM_PAINT message, the form will flash due to frequent refresh during repainting, the dual-buffer technology can effectively solve the above problems.

Flash problem:
When the form is refreshed, there must always be an OnEraseBkgnd process to erase the original image. It fills the form drawing area with the background color, and then calls the new drawing code for re-painting, the image color contrast is caused by such a wipe. When WM_PAINT responds frequently, this contrast becomes more and more obvious. So we can see the flickering phenomenon.
If only the background color is removed, the duplicate drawing will not flash. However, in that case, the form image is often messy. Because the original image is not cleared every time the image is drawn, the residual image is generated and the new image is superimposed. Therefore, it is not enough to simply prohibit background re-painting. We need to re-plot the image. The plotting function can use BitBlt, which supports copying graphic blocks and is fast.

Implementation of Double Buffer drawing:
First, draw the image to be displayed in the memory, and then overwrite the image in the memory to the screen one by one (this process is very fast, because it is a very complete copy of memory), so that after the interface is erased with the background color, the texture will not flash on the screen.
Steps:

Flowchart:

Code implementation:
Here, we use MFC on the VC ++ development platform. Generally, we use the OnDraw and OnPaint functions to draw images.
First, we will block the background refresh. The background refresh is actually responding to the WM_ERASEBKGND message. We just need to change the OnEraseBkgnd function's return value to TRUE.

// 'Direct plotting ', which causes freezing. void CDoubleBufferDlg: DrawItem (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 <1000; j ++) {pDC-> MoveTo (); pDC-> LineTo (rcClient. width (), rcClient. height (); pDC-> MoveTo (rcClient. width (), 0); pDC-> LineTo (0, rcClient. heweigh T ();} // after the drawing is complete, clear the pDC-> SelectObject (pOldPen); pOldPen-> DeleteObject ();} // 'double buffered plotting 'void CDoubleBufferDlg :: drawItemWithDoubleBuffer (CDC * pDC) {ASSERT_VALID (pDC); CRect rcClient; pDC-> GetClipBox (rcClient); // defines a memory display device context object CDC MemDC; // define a GDI bitmap object CBitmap MemBitmap; // create a memory device context environment (DC) MemDC compatible with the specified device (the screen here. createCompatibleDC (pDC); // create a bitmap compatible with the screen display. The size of the bitmap can be the size of the window customer area MemBitmap. createCompatibleBitmap (PDC, rcClient. width (), rcClient. height (); // select the bitmap object to the context of the memory display device. Only the image CBitmap * pOldBit = MemDC can be drawn. selectObject (& MemBitmap); // clear the bitmap with the white background color. Otherwise, the bitmap is black. MemDC. fillSolidRect (0, 0, rcClient. width (), rcClient. height (), RGB (255,255,255); // defines the paint brush. The color is gray CPen pen (PS_SOLID, 1, RGB (178,178,178); CPen * pOldPen = NULL; // select the paint brush object to pOldPen = MemDC in the specified device context. selectObject (& pen); // --------------------------------------------- drawing operations // need to be placed before the BitBlt function // draw an elliptical MemDC. ellipse (rcClient); // draw a diagonal line with a large number of cycles. If there is no double buffer, it will be stuck for (int I = 0; I <1000; I ++) {MemDC. moveTo (0, 0); MemDC. lineTo (rcClient. width (), rcClient. height (); MemDC. moveTo (rcClient. width (), 0); MemDC. lineTo (0, rcClient. height ();} // ----------------------------------------- Drawing operation // copy the graph in the memory to the screen for display pDC-> BitBlt (0, 0, rcClient. width (), rcClient. height (), & MemDC, 0, 0, SRCCOPY); // clear MemDC after drawing. selectObject (pOldPen); MemDC. selectObject (pOldBit); // use GetDC () to use ReleaseDC: ReleaseDC (this-> m_hWnd, MemDC); pOldPen-> DeleteObject (); MemBitmap. deleteObject ();}

:

Knowledge Concept (from Baidu encyclopedia ):
GDI
In Windows, most applications with graphical interfaces are inseparable from GDI. With the many functions provided by GDI, We can conveniently output graphics on screens, printers, and other output devices, text and other operations. So what is GDI?
GDI, short for Graphics Device Interface, refers to a graphical Device Interface. Its main task is to exchange information between the system and the drawing program and process the graphic output of all Windows programs. The emergence of this technology allows programmers to convert the output of applications into outputs on hardware devices without having to concern themselves with hardware devices and device drivers, thus realizing the isolation between program developers and hardware devices, this greatly facilitates development. GDI has the following features:

The above device environment is our device context ).

DC (device context)
In Windows, the output of each program must be limited to its own window.
GDI uses a simple mechanism to ensure that every program drawing in a window follows this rule. This mechanism is the device description table (DC). When a Windows program draws a picture on a screen, printer, or other device, it does not directly output pixels to the device, instead, the image is drawn to the "display plane" in the logic sense represented by the device description table. The device description table is a data structure that is deeply embedded in Windows. It contains all the Description fields required by GDI for displaying the plane, including connected physical devices and various status information.
The device description table, also known as the device context or device environment, is a graphical structure that defines a set of graphical objects (brushes, etc.) and their attributes and affects the output. Windows provides a device description table for interaction between applications and physical devices, which provides platform independence for application design.
A device description table is a data structure that contains information related to the drawing properties of a device (such as a display or printer. All painting operations are performed in the device description table. The device description table is different from the WIN32 structure in most cases. applications cannot directly access the device description table and can only indirectly access the structure through the handle of the device description table by various related API functions.
The device description table is always related to a system hardware device. For example, the screen device description table is related to the display device, and the printer device description table is related to the printing device.
A device description table is generally called a device description table. It corresponds to a display device. On the windows GDI interface, it is always related to a window or a display area in the window. In general, the device description table of the window generally refers to the customer area of the window, excluding the area occupied by the title bar and menu bar. For the whole window, the device description table is strictly called the window device description table, which contains all the display areas of the window. The two methods are the same, and the difference is that the operational range is different.
Once a windows window is created, it automatically generates the corresponding device description table data structure. You can use this structure to perform the GDI operation on the display area of the window, for example, dashes, writes, draws bitmaps, fills, and so on. All these operations must be performed through the device description table handle.

Copyright Disclaimer: This article is an original article by the blogger and cannot be reproduced without the permission of the blogger.