Analysis of gtk + and x used in Embedded linux

Gtk + and x Analysis for Embedded linux systems-Linux general technology-Linux programming and kernel information. For details, see the following. In Embedded Linux, there are many GUI systems, including Qt/Embedded, FLTK, Microwindows, and GTK +. What kind of GUI is used as a developer? How many changes do you make to transform a system to meet your needs? What is the size of the modified system? These are problems that developers may encounter. What we will discuss here is to make a detailed analysis of these contents. Through our discussion, you will have a definite understanding of GTK + and X-based GUI applications in embedded Linux.

With the development of embedded system applications, more and more applications need to use GUI for development to achieve better interaction.
GUI Selection in Embedded Linux is a trade-off process for most developers. Select GTK + to run on X system, and then run X system on the framebuffer embedded in the system. This is a good choice.

Advantages of GTK + and X
Of course, GTK + and X are generally considered as good combinations of large desktop systems, but they also have many advantages for Embedded Systems:
1. The X-window system and GTK + are both very stable and reliable. The X-window system has undergone long-term development and application practices. GTK + is also a mature open source code project;
2. The X-window system is a flexible client/server model structure. The crash of an application client does not affect other parts of the graphics system. This is a very important feature, it is conducive to supporting third-party application extension development without affecting the main part;
3. GTK + has two important Libraries: GDK and GLIB. GDK abstracts the underlying window management. To port GTK + to another different window system, we only need to port GDK. GLIB is a collection of tools, including data types, various macro definitions, type conversion, and string processing. Any application can connect to this GLIB library and use various data types and methods, to avoid code duplication or developers re-invent the wheel, which helps reduce the size of the entire system;
4. Cropping GTK +/X is very easy. They have good configurable options and clear code structures, this ensures that you can safely and correctly remove unnecessary code segments;
5. GTK + has a large number of applications, and GTK + has been used in many important application systems;
6. GTK + authorization is LGPL, X is non-copyleft free license, and any third-party developed systems can be linked to them;
7. GTK +/X are both based on C code, rather than C ++;
8. GTK + uses C to implement the object-oriented architecture;


Other GUI Systems
Other available graphics systems include Qt/Embedded, FLTK, and Microwindows.
1. Qt/E is relatively advanced. It is a complete, framebuffer-based GUI system developed by Trolltech;
2. Qt/E has an efficient graphic rendering effect. It also includes the TrueType font system and alpha blending translucent processing;
3. However, Qt/E does not use the LGPL authorization method, but uses two authorization Methods: Development and Use of GPL, and commercial use requires authorization and royalty;
4. Qt/E is written in C ++;
5. Qt/E is very large. An iPAQ QPE includes a 3.3 MB Qt/E library and a kb QPE Library (similar to Xlib );
6. Qt/E is not stable enough. QPE demo is good, but it has crashed;
7. FLTK (the Fast Light Toolkit) is a small GUI graphics system written in C ++ with few features and a small application scope;
8. Compared with X-Window, Microwindows is also a good choice. It occupies approximately kb-600kb of memory and file storage space. Although there is a GTK + port on it, but it is not mature enough;

X-window: much smaller than you think
For the X-window system, the majority of network developers have done a lot of work to reduce its size, the most well-known is TinyX. You can crop unnecessary code and remove static data from XLIB to reduce the overall size, such as the color management system, arc shape, and rough lines.

Most developers think that X systems are huge, but what you hear is a misunderstanding of people who do not know X well. After cropping, GTK +/X is more effective than GTK +/FB and Qt/E, and XLIB provides better support for general applications, application Development will become more efficient.

How to crop GTK +
We can crop from the standard GTK + release version, crop unnecessary ones, modify existing code, and add the Code required for new features. The crop scope includes small changes and some major structural and core changes.
1. Remove the Widgets window
In the beginning, we removed unwanted Widgets, such as GtkGamma, gtkhrloud, obsolete GtkList (replaced by GtkCList), and The GtkFrame border we don't need.

Ii. Widgets window size and drawing
Then, modify the size and Drawing Method of Widgets. GTK + provides a theme engine mechanism to control the appearance and effect of the window. It allows you to set the font, row interval, and draw features during running. This mechanism is good, but not flexible enough. Hard coding is used for many settings in the Code. In addition, a topic is a bunch of additional code segments and parameters, this will increase the overall size.

You need to find the content that affects the overall size of the window system and modify it. For example, the size and drawing of a button include the Border width, the position of x/y (the parameter required by the topic engine), the default interval (constant ), the default position (constant) in the upper left corner to obtain the focus. These do not need to be so complete in the embedded system. We can simplify the code as needed to avoid the complexity of GTK +.

In addition, using object-oriented methods to inherit the features of window Widgets is also an effective method as a subclass.

Iii. GtkWindow
GTK + always assumes that a window contains another window, which is a nested relationship. But it is not completely correct when we often encounter apps with soft keyboards. Although the keyboard belongs to a window, it will go beyond that window. To break through this assumption, you need to add some features to the GtkWindow and process the keyboard as a special subwindow.

In the window where the keyboard is located, you must handle the keyboard button events and forward the buttons to the keyboard toolbar. When the keyboard is pressed, the keyboard callback function is registered to the original window, so that the keyboard will respond to the button event. Add an interface on the GtkWindow to create the interface and press the response button.

In the embedded system of a small screen, you can simplify the scroll bar, remove the border, and use a single scroll bar. These are more suitable for embedded systems.

Font Management System
In terms of font management, it is not that simple to find a lightweight mechanism to display various fonts in an embedded system, the difficulty lies in the problems caused by the combination of GTK +'s large Widget style and X system's vintage font management mechanism.

As mentioned above, GTK + is used to control the style and appearance of the window. Before a window is displayed, it will get a style object, GtkStyle, which can be a style Object Pointer pointing to the parent window or a new type, these style objects will be applied to this window and Its subwindows. This style is determined by the default value, rc text file, and application.

To change the font of a window, you must clone the style of the window and use the X Font to load a new font, similar to adobe-helvetica-bold-r-normal -- 12-*-p-*-iso8859-1.

However, there may be some problems. GtkStyle is a large object. If a screen has multiple windows of different font sizes and each has a unique GtkStyle object, we will waste a lot of memory. At the end, the X system cannot support various changes similar to fonts. You cannot even make X bold to make a font, because X uses different fonts as different fonts. The X system assumes that you will hardcode a desired font or analyze a font name, and change the font and the verification result will be on the font server.

You can also use a better method to improve the font management system, that is, wrap the GtkStyle, so that developers can obtain the font of a window through attributes, this is more flexible than directly using the X system font name. For example, if you want to display a number bigger than the basic font, and it is in black Chinese, you can call:

Gtk_widget_set_font_bold (widget, TRUE );
Gtk_widget_set_font_enlarge (widget, 1 );

This is achieved by adding a GdkFont * font to the GtkWidget structure. GtkWidget is the parent class of all window classes. If widget-> font is set, use it; otherwise, use widget-> style-> font.

Window Management
In the embedded system GUI, you also need to create a window manager. We can choose an open code, lightweight X manager, and Aewm. In the embedded system, we set the top-level window to focus, and only the dialog box can be moved to display its title bar.
The window manager is an interactive terminal that can manage internal and external application windows. In each application window, a socket connection is established and a name is obtained. An application can put the request at the bottom of the window stack, or move a named application up. If a dialog box is to be opened in the upper-level window, the window manager will tell the upper-level window that it will no longer get the focus, and the new dialog box will get the focus.

Overall size
After a series of improvements, we have achieved a stable GUI that both functions and performance can meet the requirements of the embedded system. In the ARM system, the size is:
In GTK +, you can remove unnecessary code. To simplify the process, GTK + can be 850KB and the overall size can reach 2.8 mb.

Running Performance
Run the modified GUI on an ARM7 system with a CPU of 100 MHZ. The running performance is good, and the window responds quickly to user operations, the new screen creation and display speed are acceptable.
However, the startup time is slow. On this CPU, it takes 2.4 seconds for the app to load and display the screen, of which 1.5 seconds is spent on creating and displaying the UI.
On a slow CPU, the startup speed is caused by GTK + running on X, and X writing to framebuffer. We need to analyze the specific bottleneck. During in-depth debugging, when we use a PC to run our applications and display them on an ARM device, the initialization and display times are almost negligible. Similarly, applications run on ARM devices, and performance is good when displayed on PCs. Therefore, the transmission speed of data packets, the display on framebuffer, and the calculation speed of GTK + are not problems. The slow speed may be caused by the order of these factors. There are also problems with memory usage. In the initial stage, GTK + constructs a large number of objects. GTK + and X communicate with each other using the shared memory. X is written to framebuffer, and framebuffer is also written to the memory. These occur in the same memory space on a narrow bus, which causes slow speed.

Now we know that X takes time to start. In customer mode, GTK + applications need to connect to X server and pass authentication to obtain depth and other resources. Of course, the benefits of using the X system are far greater than its shortcomings. X system provides a flexible client/server model, which is more conducive to the flexible addition of applications. You can display unused application windows at the same time, but other GUI methods such as GTK +/Fb cannot do this. Of course, QPE is an exception.
The latency of 2.4 seconds cannot be completely negative. On a MHz windows PC, Microsoft Word, Excel, and IE take almost two seconds to start. KEdit, a kde application, takes 1.37 seconds to load on the MHz PIII.
You need to use other methods to improve the startup time. A policy is to display something to indicate that the system is working while the user is waiting, so that the user will ignore the slow startup time. Another policy is to start some common programs in advance to effectively reduce the concentrated start time. This is also common practice for embedded systems.
In the system, because there is no floating point operation FPU, it is best to remove the floating point operation in GTK +; otherwise, the performance will be greatly affected. The floating-point variables used by GTK + are only distributed in a few windows, and removing them will improve the performance by 3% to 12%.

Applications with high pixels will lead to slow speeds, most of which are due to GTK +'s inefficient processing of high pixels in X. For example, XPM and XPM (X pixmap) are designed for better compatibility, rather than faster. The X system draws the pixmap of the server in pixels. GTK +'s pixel processing is also very inefficient. It uses fgetc () to read XPM files, which leads to a large amount of context switching overhead.

The structure of the X Window System also slows down pixel loading. The GTK + client needs to load, analyze the XPM file, send the pixel value to the server through the transmission protocol, and then the server puts the pixel value into the framebuffer. If the client directly writes data to the framebuffer server, it will be much more effective.
The GTK + pixel processing method is to write a temporary intermediate process, get the render pixel, and use this raw data to replace XPM data, this raw data can be directly written to X server. In terms of structure, although this is not a good solution, it is 80% faster than XPM.

Summary
Most of the current consumer electronics require a beautiful and practical GUI system GUI. Embedded in linux, there are many GUI options. The advantage of using open code GUI is that you can crop it to meet your various special needs. GTK + is a good choice, and the X-window system provides a stable and reliable client/server model. When you get a customized GUI with a size of only 2.9M, it is of great reference value to most embedded systems.