WinCE Application: Building UI components with dynamic visual effect

1 purpose

    Building up components, more specific UI class which have professional dynamic visual effect on WinCE device.

2 Component static Overview

        graph1.   UI component static architecture

    Each component is a subclass of MFC basic UI class(I forgot the class name), so it have on-paint method which would refresh its graphic content on the screen. The UI component need double frame buffer to avoid screen dizzy, that means every layer have it's own buffer in the memory. The layer 0 stores the background picture from the main window, so when the component is initialized, the windows need to tell it what picture the main window is using, so that the UI component would remember the background resulting seamless visual effect. Layer 1 stores the component's own background. Layer 2-n is the drawing object which would dynamic change. Drawing on each layer resulting in a buffer which would be used next time if the layer have no change. To avoid overriding the content when merging the layers, A bitmap would be used to indicate which pixels should not be merged in the forground and background, or a transparent bit build function which use a specified RGB indicating pixels overriding.

3 runtime architecture

   

        graph2. runtime structure

    To show dynamic visual effect, there must be a separate thread or MFC timer to "kick" each UI instance installed in current window, ask that if it need a refresh action. This is better for performance than letting each of UI component instance having its own visual effect thread. If the component is at visual effect active state, such as it accepted a push action, then calculate the dynamic effects for each layer with a function based on time f(t). If one layer need to be update, then redraw it, otherwise using previous buffer. Then merge all layer to final picture, and sending a re-paint message to MFC framework, resulting on-paint() function called where real screen would be updated from final picture for the component. The function f(t) holds the tricks to show funny visual effects such as sizing, sliding, usually it is related to physical formula in real world.

4 performance in embbed device

   

        graph 3.  Hardware related to UI

    Visual effect consume system resource highly, So before writing the program it is better to take a look at the hardware device it would be running. Typically ARM 9 generation would have a simple 2D GPU unit outside the ARM core, and the bus frequency is blow 100Mhz, which would likely be the bottle neck. For eg, a UI having 640x480 resolution, would require a bandwidth for moving the data: 640width x 480height x 3bpp x 25fps x (n+1+1)layers = 23.04M x (n+2) bytes. So this brings obvious pressure to the system, if the device is found at this situation, the UI component should limit its size, layers, update frequency, and the main window should consider how many UI component instances the system could afford. If the GPU hardware supports DMA, then this burden would be easier. In my test, the best resolution on ARM 9 with pure software visual component is about 400x300, in which situation the visual effects seems smooth.

    The newer generation of ARM often get an intergrate GPU unit inside the CPU, and usually it supports DirectDraw which allow application write buffers on GPU directly, which removes the bottle neck if software use DirectDraw API. The bus bandwidth is also much faster, so pure software component works well either. Check both hardware and platform BSP about the DirectDraw component.

5 MVC

    When using dynamic visual effect component, personally I think it must use MVC method to divide the functions and classes. The UI component class cares only about the visual content, let other class handles the logical entity and controlling, Otherwise the codes for UI mixed with logical would make things mess.