Embedded 3D graphics is here, but 2D is still important: Here’s whyIn this Product How-To article, Fujitsu’s Waqar Saleem compares 2D and 3D graphics techniques in embedded designs and then describes an approach that combines the benefits of both techniques, using the company’s IRIS fast pixel engine- based MB86R1x and MB9EF126 CPUs to illustrate a typical 2D/3D configuration.
Sophisticated 3D graphics capabilities are starting to appear in embedded devices such as cell phones and tablets. However, 2D graphics are still needed in applications that either use 2D graphics only or use both 2D and 3D capabilities.
For example, POS terminals, industrial devices, and mid- to low-end automotive graphics applications only need 2D graphics, while some high-end automotive navigation systems may need both 2D and 3D for GUI implementation. In these hybrid applications, effective use of 2D can allow the 3D engine to focus on the most graphics-intensive operations.
Given the importance of two-dimensional graphics in embedded apps, it’s important to understand two common approaches to 2D graphics: raster and vector graphics. This article compares the two techniques, then describes an approach to embedded graphics that combines the benefits of both techniques. The embedded application used as an example is for automotive designs.
To begin, let’s assume familiarity with embedded systems and terms such as Flash ROM, CPU RAM, and VRAM. The discussion is based on typical system configurations such as the one shown in Figure 1a above and Figure 1b below.
Figure 1: (b) Single-chip Embedded Architecture
Raster Graphics Engines
Raster graphics rely on pre-rendered images or bitmaps for operation. If it’s a multi-chip application, the bitmaps will typically be stored in the off-chip CPU Flash ROM. In a true single-chip solution, they will reside in a dedicated external Flash chip, which can be connected via a serial or parallel bus to the graphics chip. Raster engines use Block Transfer (BLT) operation to transfer the bitmaps to the graphics engine. BLT operation is similar to memcopy operation.
There are two common architectures for raster graphics engines, as shown in Figure 2 below. One uses the line-buffer mechanism. This technique does not need a frame buffer for pre-composing scenes. It fetches bitmaps (sometimes called sprites) one line at a time. The advantage is a smaller or no VRAM requirement, but the engine can quickly run out of steam if the application demands fairly dynamic graphics content.
The other architecture uses a frame buffer in VRAM. All bitmaps that are supposed to show up on the display are BLTed from Flash memory into VRAM ahead of time. The graphics engine will combine the bitmaps in the desired order to create the final scene, which will then be sent to the display. The choice of architecture depends on the application. This type of raster graphics architecture is useful if the application needs a really dynamic visual.
Vector Graphics Engines
Vector graphics engines are much more powerful than raster engines. In addition to handling pre-rendered bitmaps, vector engines can generate dynamic graphics elements on the fly, and can draw a 2D object using paths/primitives based on an input of mathematical equations.
The engine can then give the object a real-life look using color fills and texture maps. Such engines can also translate, rotate, and scale the 2D objects using matrix multiplication.
The most popular vector graphics engine in embedded systems is OpenVG 1.1, which is based on an open standard defined by Khronos. Every semiconductor company will have its own implementation of this standard. The power, performance, and efficiency depend on the design. Figure 3 below shows the OpenVG pipeline concept from Khronos.
Click on image to enlarge.
Figure 3: OpenVG Pipeline Concept [Image based on graphic from http://www.khronos.org/openvg/]
Comparison of Raster and Vector Graphics Engines
Raster and vector engines have their pros and cons. Raster engines are simpler and less expensive to design and implement. They rely on pre-rendered graphics and don’t have to do dynamic computations during operation. They can be designed without much difficulty using BLT-ers or memory-fetch units that transport bitmaps from permanent storage (Flash) to either a line buffer or VRAM.
However, memory storage and bandwidth requirements for these engines can become excessive if the application requires long animated sequences or sophisticated effects, such as image scaling or rotation. Another drawback of raster engines is that image quality can be adversely affected if they need to scale up the image.
On the other hand, vector engines are excellent at handling dynamic graphics. They can create 2D objects from scratch using paths/ primitives, color fills, and texture maps, based on a set of mathematical equations. Another benefit is the engine’s low memory size requirement.
These engines do not need bitmap sequences to show animation. They can translate, scale, and rotate 2D objects without consuming much memory. They can also handle fonts well. However, this comes at the price of a complicated design. The vector engine or IP cab costs a lot as well, and these engines still need significant memory to show sophisticated graphics at a high frame rate.
Currently no items