Content rendering speed is the key to determining the success of a UI. No matter how gorgeous the UI is, no speed is meaningless.
In the development framework such as MFC,WTL, each control is a window, the window needs only to draw foreground, background. Because the content between the Windows does not need to be mixed, a single refresh of a subwindow only involves the window itself, and is not related to other windows, so it is efficient. But the drawback is that the window between the content is isolated, to the different windows between the content of more coordination, the fine arts have a high demand, but also basically can only adapt to individual window size relatively fixed scene.
The simplest and most effective way to make the UI more beautiful is to mix the windows of each layer in an alpha blend so that there is no boundary between the windows, which makes the UI more like a whole, which is the main implementation of the modern UI.
Imagine how the UI system would draw the contents of a window if the content of a sub-window of the topmost layer had changed.
First you need to inform the UI system that the render object says my window display area content has changed and requested repainting.
After the UI system has taken the rendered object, it sets the clipping area (clip) on the render range to prevent the areas that do not need repainting from being refreshed.
The UI system draws the contents of each layer's overlapping window from the topmost window (the blending of the drawn content between the different Windows is defined by the drawing method, and the sample may be using the alpha channel).
To prevent flicker during the drawing process, it is generally done on a memory drawing device (such as a memory DC). After all draws are complete, the drawing content is then rendered to the screen.
So the problem is: the normal child window will be smaller than the parent window, when the child window requests repainting, to execute the parent window's drawing function, if the parent window does not determine its own drawing extent according to the current clipping extent, then although there is clipping area limit does not draw beyond the boundary, in the actual execution process, Drawing behavior beyond the clipping area can also greatly affect the performance of the UI.
How to solve this problem?
There are a number of ways to solve this, such as when each window's drawing method implements only the portion of the clipping area (which is actually cumbersome to implement, the additional clipping area calculation may also be the new drawing bottleneck), or if each window retains the contents of the background window, and when the window needs to be refreshed, Directly take the background content and draw it over it.
The second method seems to be the most efficient, but it may not actually be high: although it is faster to draw your own content, the problem is that when you update it yourself, you also need to update the cache of its upper-level windows at the same time, which can lead to high memory overhead and low efficiency.
In Soui, we adopted a third method: Add a Cache property to the window.
When cache=0, the window is drawn as in the previous process, except that if the window is larger, the area that needs to be 1:30 is compared to an hour, and the speed is slower.
If cache=1, the content drawn by the window is saved to a cached bitmap, which is copied directly from the cache when other Windows refresh and cause the window to redraw.
Suppose a window uses a small picture to draw out nine Gongra, drawing the entire window due to the interpolation in the stretching of a series of calculations, drawing may need to consume a lot of CPU time, and after the cache, only the first time when drawing using the picture drawing method to draw, the other time is directly from the cache copy, The efficiency can be greatly improved.
It is clear that the cache property, while improving rendering efficiency, also requires a cache to hold the drawing content, which is the usual way of space-time change. So if the drawing itself is fast enough, then it is entirely possible not to use the cache (for example, to fill a window with a solid-colored rectangle).
Summarize:
The cache can improve drawing speed, but at the expense of a higher memory footprint, it should only be used where needed (such as the top-level background window).
17th: Accelerating Soui rendering using the window's Cache property