GUI Frameworks: Difference between revisions
No edit summary |
TomCooksey (talk | contribs) No edit summary |
||
Line 4: | Line 4: | ||
NOTE: LinuxDevices has a more detailed guide to embedded graphics [http://linuxdevices.com/articles/AT9202043619.html here], although this is quite old now. | NOTE: LinuxDevices has a more detailed guide to embedded graphics [http://linuxdevices.com/articles/AT9202043619.html here], although this is quite old now. | ||
== Back Ends == | == Back Ends == | ||
=== Frame buffer (FBDev) === | |||
Most Linux systems on embedded devices only provide a frame buffer device. This allows an application to memory-map the pixels on the screen and write to them as if it was a regular array. This frame buffer interface is universal across all architectures and all devices, allowing applications utilising the frame buffer to be ported easily. The disadvantage is that quite often the [[Application Processor]] has more advanced graphics hardware for rendering which is not utilized by the frame buffer interface. | |||
=== DirectFB === | |||
[http://www.directfb.org DirectFB] addresses the issue of not utilising hardware acceleration by providing applications with a more advanced programming interface. Common graphics operations such as line drawing, blit'ing and basic windowing are provided. When the underlying hardware is able to accelerate these operations, this acceleration is used. When hardware acceleration is not available, the operation is performed in software, providing maximum compatibility for applications. While this is an excellent project, the number of hardware devices supported are small and does not include any CPUs you'd find on a phone. This may, of course change in the future. | |||
=== nano-X === | |||
An alternative to using a frame buffer device is to use an x server as you would on a desktop PC. There are many (MANY) applications out there which use X. The problem with x servers are their footprint. Both memory and storage requirements of a normal x server are too large for small embedded systems. To address this, an x-like server has been produced called [http://www.microwindows.org/ Nano-X]. While not conforming to the X windows API, the API is similar, allowing X windows applications to be ported. The last item of news on the nano-x site is dated 2005, so this project may be dead. | |||
=== Micro-x/KDrive === | |||
Unlike nano-x, [http://www.pps.jussieu.fr/~jch/software/kdrive.html KDrive] is a complete X server and even supports the RENDER X windows extensions. Although KDrive is a full X Server, it goes to great lengths to not become bloated and is designed with embedded systems in mind. As KDrive supports the RENDER extensions, accelerating drawing operations in hardware is possible, but requires modification for the target [[Application Processor]]'s graphics core. As with DirectFB, the list of supported hardware accelerated hardware does not include graphics cores found in phones. There is an x server for the HP IPaq, however this simply uses the standard frame buffer and adds support for the VGA-Out device. | |||
=== OpenKODE === | |||
[http://www.khronos.org/openkode/ OpenKODE] is a new specification for mobile devices and includes [http://www.khronos.org/opengles/ OpenGL ES], [http://www.khronos.org/openvg OpenVG], [http://www.khronos.org/openmax OpenMAX] and similar into a single, integrated API. The emphases here is hardware acceleration. OpenKODE is cross platform and is gathering a lot of industry support. One reason why this might be of interest is rather nicely demonstrated by nVidia in this user interface demo which uses an OpenKODE 1.0 implementation: [http://www.youtube.com/watch?v=8kLFPfaxQ6U&eurl= Next-Gen Phone Interface]. There are currently no open source implementations of the OpenKODE specification, however there are OpenGL ES & OpenVG (binary) Linux drivers available for PowerVR [http://www.imgtec.com/PowerVR/products/Graphics/MBX/index.asp MBX] & [http://www.imgtec.com/PowerVR/products/Graphics/SGX/index.asp SGX] cores, found in higher-end [Application Processors]. These drivers are not available from Imagination Technologies (who designed the PowerVR series) directly but are instead supplied with the BSP for your chosen CPU. | |||
Line 23: | Line 27: | ||
A widget toolkit provides useful widgets such as buttons, menus, text boxes etc. The application programmer doesn't care what a button looks like, just what happens when it's pressed. On embedded systems, you generally have two choices: GTK+ or QT. However, more advanced, Flash based user interfaces are becoming more popular on mobile phones. Sadly, there are currently no open source equivalents at present. | A widget toolkit provides useful widgets such as buttons, menus, text boxes etc. The application programmer doesn't care what a button looks like, just what happens when it's pressed. On embedded systems, you generally have two choices: GTK+ or QT. However, more advanced, Flash based user interfaces are becoming more popular on mobile phones. Sadly, there are currently no open source equivalents at present. | ||
=== GTK+ === | |||
GTK+ has excellent support on embedded systems. Ports of GTK+ have been made for rendering directly to the frame buffer, to a DirectFB device and of course KDrive. For more information about GTK+, visit [http://www.gtk.org]. | |||
=== QT/Qtopia === | |||
QT is a commercial product written by a company called [http://www.trolltech.com Trolltech]. However, Trolltech uses a dual license scheme where it releases QT under the GPL. This means that if you also use the GPL to license your application, you can use QT for free. QT as it stands is unsuitable for embedded devices due to it's large size and large dependency tree. However, a few years ago, Trolltech launched an embedded version of QT, cleverly named Qt/Embedded. While this is still used for the OPIE application framework, Troltech have updated Qt/Embedded and produced their own framework called Qtopia. Out of the box, both Qt/Embedded and Qtopia render directly to the frame buffer. In Qtopia, it is possible to accelerate this rendering by re-implementing several of the classes the library uses to perform all drawing operations. The Both QT/Embedded & the Qtopia framework also handles windowing when multiple applications are running. | |||
Line 31: | Line 37: | ||
The widget toolkits provide facilities for applications to draw buttons on the screen, but what if they want to find a telephone number? On a typical phone, lots of different applications are going to need a contact list. Having a different contact list for each application is going to get silly. Instead, there are two application toolkits available, Qtopia which uses QT widgets and the other is called GPE and is based on GTK+. This is similar to the KDE vs Gnome dilemma, just on embedded devices. The choice between Qtopia and GPE is more critical however. Qtopia applications use the built-in windowing system provided by the Qtopia framework which in turn renders directly to the frame buffer. GPE uses an X-server, which (usually) also renders directly to the frame buffer. The result is that it's a one or the other thing. GPE applications can't run simultaneously with Qtopia applications. Once way around this would be to port Qtopia (back) to X windows and let the X server handle windowing. | The widget toolkits provide facilities for applications to draw buttons on the screen, but what if they want to find a telephone number? On a typical phone, lots of different applications are going to need a contact list. Having a different contact list for each application is going to get silly. Instead, there are two application toolkits available, Qtopia which uses QT widgets and the other is called GPE and is based on GTK+. This is similar to the KDE vs Gnome dilemma, just on embedded devices. The choice between Qtopia and GPE is more critical however. Qtopia applications use the built-in windowing system provided by the Qtopia framework which in turn renders directly to the frame buffer. GPE uses an X-server, which (usually) also renders directly to the frame buffer. The result is that it's a one or the other thing. GPE applications can't run simultaneously with Qtopia applications. Once way around this would be to port Qtopia (back) to X windows and let the X server handle windowing. | ||
=== GPE Palmtop Environment === | |||
From GPE's homepage: "''The GPE Palmtop Environment aims to provide a Free Software GUI environment for palmtop/handheld computers running the GNU/Linux™ operating system. GPE uses the X Window System, and the GTK+-2.6 widget toolkit. | |||
GPE is not a single piece of software, but an entire environment of components which make it possible to use your GNU/Linux handheld for standard tasks such as Personal Information Management (PIM). GPE makes it easy for developers to create powerful programs, by giving them the infrastructure they need. | GPE is not a single piece of software, but an entire environment of components which make it possible to use your GNU/Linux handheld for standard tasks such as Personal Information Management (PIM). GPE makes it easy for developers to create powerful programs, by giving them the infrastructure they need. | ||
Line 41: | Line 46: | ||
A recent development has been the launch of [http://gpephone.linuxtogo.org GPE Phone edition]. This aims to implement a complete [http://www.lipsforum.org/ LIPS] compliant software stack. For more information on GPE in general, visit [http://gpe.handhelds.org] | A recent development has been the launch of [http://gpephone.linuxtogo.org GPE Phone edition]. This aims to implement a complete [http://www.lipsforum.org/ LIPS] compliant software stack. For more information on GPE in general, visit [http://gpe.handhelds.org] | ||
=== Qtopia === | |||
from Qtopia's homepage: "'' Qtopia is unrivaled as the application platform and user interface for Linux, allowing efficient creation of mobile and embedded devices.''" | from Qtopia's homepage: "'' Qtopia is unrivaled as the application platform and user interface for Linux, allowing efficient creation of mobile and embedded devices.''" | ||
Qtopia is split up into different versions, including a Qtopia Phone Edition. Qtopia core is name given to the actual application framework. Apart from several demos and examples, Qtopia cores does not come with any applications. Applications are included in the "Open Source Edition" and "Phone Edition". For more information, visit [http://www.trolltech.com/products/qtopia]. | Qtopia is split up into different versions, including a Qtopia Phone Edition. Qtopia core is name given to the actual application framework. Apart from several demos and examples, Qtopia cores does not come with any applications. Applications are included in the "Open Source Edition" and "Phone Edition". For more information, visit [http://www.trolltech.com/products/qtopia]. | ||
=== Open Palmtop Integrated Environment (OPIE) === | |||
Originally started as an alternative GUI for the Sharp Zaurus, OPIE has now spread across several devices and has a large collection of applications. Opie uses an older version of QT/Embedded which lacks many of the feature of the more modern Qtopia. However, due to it's stability & large application base it remains a very interesting prospect. More information at [http://opie.handhelds.org] | Originally started as an alternative GUI for the Sharp Zaurus, OPIE has now spread across several devices and has a large collection of applications. Opie uses an older version of QT/Embedded which lacks many of the feature of the more modern Qtopia. However, due to it's stability & large application base it remains a very interesting prospect. More information at [http://opie.handhelds.org] |
Revision as of 12:52, 4 April 2007
The GUI framework is the software library which allows applications to put pixels onto the LCD. It handles contention between applications, deals with windows and usually provides an abstraction away from pixel-by-pixel drawing through widget libraries.
On a desktop system, this is separated into several components: An X-server which allows client applications to connect and draw things in the client's window. Then there are the widget toolkits, where you generally have a choice between Motif, GTK or QT (there are many others, but these are the more common ones). On an embedded system, this separation is not always as clear cut.
NOTE: LinuxDevices has a more detailed guide to embedded graphics here, although this is quite old now.
Back Ends
Frame buffer (FBDev)
Most Linux systems on embedded devices only provide a frame buffer device. This allows an application to memory-map the pixels on the screen and write to them as if it was a regular array. This frame buffer interface is universal across all architectures and all devices, allowing applications utilising the frame buffer to be ported easily. The disadvantage is that quite often the Application Processor has more advanced graphics hardware for rendering which is not utilized by the frame buffer interface.
DirectFB
DirectFB addresses the issue of not utilising hardware acceleration by providing applications with a more advanced programming interface. Common graphics operations such as line drawing, blit'ing and basic windowing are provided. When the underlying hardware is able to accelerate these operations, this acceleration is used. When hardware acceleration is not available, the operation is performed in software, providing maximum compatibility for applications. While this is an excellent project, the number of hardware devices supported are small and does not include any CPUs you'd find on a phone. This may, of course change in the future.
nano-X
An alternative to using a frame buffer device is to use an x server as you would on a desktop PC. There are many (MANY) applications out there which use X. The problem with x servers are their footprint. Both memory and storage requirements of a normal x server are too large for small embedded systems. To address this, an x-like server has been produced called Nano-X. While not conforming to the X windows API, the API is similar, allowing X windows applications to be ported. The last item of news on the nano-x site is dated 2005, so this project may be dead.
Micro-x/KDrive
Unlike nano-x, KDrive is a complete X server and even supports the RENDER X windows extensions. Although KDrive is a full X Server, it goes to great lengths to not become bloated and is designed with embedded systems in mind. As KDrive supports the RENDER extensions, accelerating drawing operations in hardware is possible, but requires modification for the target Application Processor's graphics core. As with DirectFB, the list of supported hardware accelerated hardware does not include graphics cores found in phones. There is an x server for the HP IPaq, however this simply uses the standard frame buffer and adds support for the VGA-Out device.
OpenKODE
OpenKODE is a new specification for mobile devices and includes OpenGL ES, OpenVG, OpenMAX and similar into a single, integrated API. The emphases here is hardware acceleration. OpenKODE is cross platform and is gathering a lot of industry support. One reason why this might be of interest is rather nicely demonstrated by nVidia in this user interface demo which uses an OpenKODE 1.0 implementation: Next-Gen Phone Interface. There are currently no open source implementations of the OpenKODE specification, however there are OpenGL ES & OpenVG (binary) Linux drivers available for PowerVR MBX & SGX cores, found in higher-end [Application Processors]. These drivers are not available from Imagination Technologies (who designed the PowerVR series) directly but are instead supplied with the BSP for your chosen CPU.
Widget Toolkits
A widget toolkit provides useful widgets such as buttons, menus, text boxes etc. The application programmer doesn't care what a button looks like, just what happens when it's pressed. On embedded systems, you generally have two choices: GTK+ or QT. However, more advanced, Flash based user interfaces are becoming more popular on mobile phones. Sadly, there are currently no open source equivalents at present.
GTK+
GTK+ has excellent support on embedded systems. Ports of GTK+ have been made for rendering directly to the frame buffer, to a DirectFB device and of course KDrive. For more information about GTK+, visit [1].
QT/Qtopia
QT is a commercial product written by a company called Trolltech. However, Trolltech uses a dual license scheme where it releases QT under the GPL. This means that if you also use the GPL to license your application, you can use QT for free. QT as it stands is unsuitable for embedded devices due to it's large size and large dependency tree. However, a few years ago, Trolltech launched an embedded version of QT, cleverly named Qt/Embedded. While this is still used for the OPIE application framework, Troltech have updated Qt/Embedded and produced their own framework called Qtopia. Out of the box, both Qt/Embedded and Qtopia render directly to the frame buffer. In Qtopia, it is possible to accelerate this rendering by re-implementing several of the classes the library uses to perform all drawing operations. The Both QT/Embedded & the Qtopia framework also handles windowing when multiple applications are running.
Application Frameworks
The widget toolkits provide facilities for applications to draw buttons on the screen, but what if they want to find a telephone number? On a typical phone, lots of different applications are going to need a contact list. Having a different contact list for each application is going to get silly. Instead, there are two application toolkits available, Qtopia which uses QT widgets and the other is called GPE and is based on GTK+. This is similar to the KDE vs Gnome dilemma, just on embedded devices. The choice between Qtopia and GPE is more critical however. Qtopia applications use the built-in windowing system provided by the Qtopia framework which in turn renders directly to the frame buffer. GPE uses an X-server, which (usually) also renders directly to the frame buffer. The result is that it's a one or the other thing. GPE applications can't run simultaneously with Qtopia applications. Once way around this would be to port Qtopia (back) to X windows and let the X server handle windowing.
GPE Palmtop Environment
From GPE's homepage: "The GPE Palmtop Environment aims to provide a Free Software GUI environment for palmtop/handheld computers running the GNU/Linux™ operating system. GPE uses the X Window System, and the GTK+-2.6 widget toolkit.
GPE is not a single piece of software, but an entire environment of components which make it possible to use your GNU/Linux handheld for standard tasks such as Personal Information Management (PIM). GPE makes it easy for developers to create powerful programs, by giving them the infrastructure they need.
Besides providing core software such as shared libraries, and perhaps more importantly, the GPE environment fixes standards for program interaction, such as SQL, XML, and other data schemas."
A recent development has been the launch of GPE Phone edition. This aims to implement a complete LIPS compliant software stack. For more information on GPE in general, visit [2]
Qtopia
from Qtopia's homepage: " Qtopia is unrivaled as the application platform and user interface for Linux, allowing efficient creation of mobile and embedded devices."
Qtopia is split up into different versions, including a Qtopia Phone Edition. Qtopia core is name given to the actual application framework. Apart from several demos and examples, Qtopia cores does not come with any applications. Applications are included in the "Open Source Edition" and "Phone Edition". For more information, visit [3].
Open Palmtop Integrated Environment (OPIE)
Originally started as an alternative GUI for the Sharp Zaurus, OPIE has now spread across several devices and has a large collection of applications. Opie uses an older version of QT/Embedded which lacks many of the feature of the more modern Qtopia. However, due to it's stability & large application base it remains a very interesting prospect. More information at [4]