1# Overview of Small-System Graphics
2
3## Overview
4The small-system graphics framework, a lightweight graphics framework, includes lightweight UI components, animations, events, 2D graphics libraries, font layout engines, multi-backend rendering, and window manager modules. It is mainly used for UI display on small-system devices with screens, such as sports watches and smart home devices.
5
6### Relationship Between UIs in OpenHarmony
7You may have learned different development paradigms of OpenHarmony. What is the relationship between them and the small-system graphics framework?
8
9Currently, the [ace_engine repository](https://gitee.com/openharmony/arkui_ace_engine) implements two development frameworks: ArkUI declarative development paradigm and ArkUI web-like development paradigm. For details about their differences, see [ArkUI Overview](../../application-dev/ui/arkui-overview.md). Based on the characteristics of the small system, the [ace_engine_lite repository](https://gitee.com/openharmony/arkui_ace_engine_lite) implements the lightweight ArkUI web-like development paradigm, which is named ArkUI web-like development paradigm lite. Its capabilities are a subset of the ArkUI web-like development paradigm.
10
11OpenHarmony supports the following development modes by system type:
12- Standard system:
13  - ArkUI declarative development paradigm (recommended)
14  - ArkUI web-like development paradigm
15- Small system:
16  - ArkUI web-like development paradigm lite
17  - C++ development (for system applications)
18
19The figure below shows the code implementation relationship between [ui_lite](https://gitee.com/openharmony/arkui_ui_lite), [ace_engine_lite](https://gitee.com/openharmony/arkui_ace_engine_lite), and [ace_engine](https://gitee.com/openharmony/arkui_ace_engine) in the small-system graphics framework.
20
21![ui relationship](figures/openharmony_ui.png)
22
23When determining the API suite used for your application development, preferentially select the ArkUI declarative development paradigm for the standard system and the ArkUI web-like development paradigm lite for the small system. When developing a system application on devices with low configurations, you can use C++ APIs for higher performance and better flexibility.
24
25
26### UI Components
27The small-system graphics framework implements basic components, such as button, text, and progress bar.
28
29It also provides complex components such as list, swiper, and image sequence frame.
30
31### Layouts
32The framework implements grid layout and flexible layout (such as centered, left-aligned, and right-aligned).
33
34As each layout is a one-off, the positions of components in a specific layout are calculated each time related functions are called on the layout. However, if the position of a component changes with an operation (dragging for example), the positions of other associated components do not automatically change.
35
36### Animations
37The framework supports custom animations. All animations are managed by AnimatorManager. Based on the screen refresh event, AnimatorManager periodically calls the callback functions to process attribute changes and then triggers component re-rendering to achieve the animation effect.
38
39You can call related functions to start, stop, pause, resume, create, and destroy an animation.
40
41### Events
42Input events include touchscreen and physical key input events. Each time the GUI engine runs, InputManager reads the input of all registered hardware devices and converts the input into various events for UI components to use.
43
44### Rendering
452D graphics rendering: Draws lines, rectangles, triangles, and arcs.
46
47Image rendering: Draws images of various types, such as RGB565, RGB888, ARGB8888, PNG, and JPG.
48
49Font rendering: Draws vector fonts in real time.
50
51## Implementation Principles
52
53In the small-system graphics framework, the task queue is driven by the screen refresh signal. The task queue stores every task. A periodic screen refresh signal triggers a periodic callback to cyclically drive the execution of a task in the task queue. Operations such as input events, animations, and rendering are executed as independent tasks.
54
55### Event Interaction
56
57The small-system graphics framework supports the touch event (PointerInputDevice), key event (KeyInputDevice), and crown rotation event (RotateInputDevice).
58
59```mermaid
60classDiagram
61
62class InputDevice {
63     +Read(DeviceData& data): bool
64}
65
66class PointerInputDevice {
67    +Read(DeviceData& data): bool
68}
69
70class RotateInputDevice {
71    +Read(DeviceData& data): bool
72}
73
74class KeyInputDevice {
75    +Read(DeviceData& data): bool
76}
77
78
79class InputManager {
80    -deviceList_: List<InputDevice*>
81}
82
83InputDevice <|-- PointerInputDevice
84InputDevice <|-- RotateInputDevice
85InputDevice <|-- KeyInputDevice
86Task <|-- InputManager
87InputManager *-- InputDevice
88```
89
90The figure above shows the input event classes. Each type of input event overrides the **Read** function of the **InputDevice** base class based on its own features, reads input data, generates an event based on the input data, and distributes the event to the corresponding UI component. For example, **PointerInputDevice** reads the touch coordinates, searches for the component corresponding to the coordinates from the component tree, generates a touch, touch and hold, or drag event, and distributes the event to that component.
91
92### Animation Framework
93
94```mermaid
95classDiagram
96
97class AnimatorCallback {
98     +Callback(UIView* view): void
99}
100
101class Animator {
102    +Start(): void
103    +Stop(): void
104    -callback_: AnimatorCallback*
105}
106
107class AnimatorManager {
108    -list_: List<Animator*>
109}
110
111Task <|-- AnimatorManager
112AnimatorManager *-- Animator
113Animator *-- AnimatorCallback
114```
115
116To implement a custom animation, you need to inherit from the **Animator** class and implement the callback function of **AnimatorCallback**. All animations are managed by **AnimatorManager** in a unified manner. The input parameter of the callback function is **view** (component) of the current animation. You can modify the component attributes to generate the animation effect, such as the coordinate change, color change, and zoom effect.
117
118### Rendering Framework
119
120```mermaid
121classDiagram
122
123class WindowImpl {
124    Render: void
125}
126
127class UIView {
128    OnDraw: void
129    Invalidate : void
130}
131
132class RootView {
133    Measure: void
134    Render : void
135}
136
137class RenderManager {
138    +Callback: void
139    -winList_: List<Window*>
140}
141
142Task <|-- RenderManager
143Window <|-- WindowImpl
144UIView <|-- RootView
145WindowImpl *-- RootView
146RenderManager *-- Window
147```
148
149 - Each window has a **RootView**.
150 - **RootView** is the root node of a window. All components in a window can be displayed only after being mounted to **RootView**.
151 - **UIView** is the base class of all components. Each component implements its own **OnDraw** function.
152 - When the display of a component changes, the **Invalidate** function is called to mark the current area as a dirty area.
153 - **RootView** manages information about all dirty areas in a window.
154 - Each time a screen refresh signal is triggered, all windows are traversed and rendered. For each window, the **Measure** function is called for layout from **RootView**, and then the **Render** function is called to render the components in all the dirty areas.
155