Today we have a guest-blogger appearance. Phil Brumby is a Senior Technical Marketing Engineer for our Runtime Solutions team and manages the technical and engineering developments for development for our graphics and user interface products. He led a web seminar a few weeks ago titled “Create Compelling User Interfaces for Embedded with Qt Framework” and received more questions than he had time to answer during the live session. What follows is an expansion of the Q&A. Enjoy.
Last week I hosted a webinar on the topic of creating compelling UI for embedded devices with the Nucleus Add-on for the Qt® Framework. This webinar was very well attended, and out of that we had a large and varied set of questions submitted during the Q/A session. As a follow up in this blog post I thought I would expand on some of the questions that came up.
Specific to actual use of the Nucleus Add on for Qt® Framework product we had:
Can an existing Qt Widget based project be used?
The answer to this is very much yes! Qt is widely used within the embedded development community, so the ability to import existing QWidget based projects into our development tools was a key development feature. Within the CodeBench IDE you will find an Import Existing Qt Project as Nucleus Qt Project option, this takes your existing Qt project and via the .pro file creates a buildable Nucleus for Qt application including all your Qt Widget forms, form classes and qrc files.
Can the out of the box UI widgets look and feel be customized with the tools you provide?
Very much so, and this really is the purpose of the UI product. Each of the UI widgets can be edited to have a different look and feel, sometimes called style or brand, across multiple projects and even multiple styles with in a single project. They would all still maintain the same core functionality, like that associated with a button or control slider for example, but look different. These look and feel changes can be made within the WYSIWYG Qt Design tool or natively within the application code. They can also have simple logic, or conditions, applied to them that change their style at runtime based on the value of a system variable for example.
On the topic of use with other operating systems, for both development target and host, we had a number of questions:
Is it possible to use Qt with the CodeBench IDE for embedded linux? Does the CodeBench IDE run also on the linux desktop? Can you performance profile a QT application for other OSs using Sourcery Analyzer?
First we need to distinguish between development host platform support and embedded device target platform support. On the target side Mentor supports Qt for both the Nucleus RTOS and our Mentor Embedded Linux OS product. Sourcery Analyzer and the Qt analysis agents as well as the Qt instrumentation are available for both Nucleus and Mentor Embedded Linux. On the host side, the current Nucleus version supports Windows. Linux host support for Nucleus is on our roadmap.
Finally outside the scope of the product and more related to the topic of understanding embedded UI development we had:
What requirements should be fulfilled by an embedded processor to have a good performance?
This is an interesting question and one that often comes up when discussing embedded UI development. It makes sense to think of the “minimum processor spec” as the power necessary to achieve an acceptable level of responsiveness, and an acceptably smooth frame rate during on-screen animations (fps).
You should look to the size and style of UI you are creating to make an informed decision on the processor needed, not just what features the processor has. UI performance is variable, a key point to understanding UI performance is that it is often render-bound, that is, the more pixels that you have to render, the greater the performance cost.
This will depend on a number of things:
- Resolution, the width and height of screen in pixels, the higher the resolution the greater number of pixels you will have to push around
- Animations, the quantity and size of your UI animations. If you have full screen transitions or large areas of the screen constantly animating.
- UI complexity – Is your design 2D, 2.5D, 3D? By 2.5D I refer to depth perspective, making use of the Z plane to push object backwards or forwards in the view plane. True 3D design would make use of 3D objects, that is a 3D model or mesh made from polygons. Use of the Z plane is typically more costly, as with 3D which will require a GPU and OpenGL/ES 2.0 integration
- Screen colour depth, or number of bits per pixel, the higher the bit per pixel rate, the larger the amount of data that has to be processed.
- Availability of hardware-accelerated graphics APIs. If your target hardware has an GPU that supports OpenGL/ES 2.0 acceleration then some of rendering costs can be pass to it.
Assessing your UI along these points will help you decide the processor power required.