Drawing Strategy

Every visual element in a user interface is drawn in one of three ways. The three are not mutually exclusive: a single screen routinely combines more than one, such as a raster image for a photo or an icon, raster primitives for a runtime gauge, and vector graphics for artwork that must scale. The choice is therefore made for each element rather than once for the whole UI, and it still matters: one of the three is gated by a hardware capability of the VEE Port, so it is not a free stylistic pick.

Strategy

Library

API

Always available?

Raster image

MicroUI

Painter.drawImage (Image / ResourceImage)

Yes

Raster primitives

MicroUI

Painter, ShapePainter, TransformPainter (lines, shapes, text, etc.)

Yes

Vector graphics

MicroVG

VectorGraphicsPainter (VectorImage, Path, VectorFont, etc.)

No (requires a vector GPU, see below)

Capability Gate

The three strategies do not share the same availability: two always work, the third is gated by the VEE Port hardware.

  • Raster image is always available: the GPU blits it where it supports the image’s format, and any format it cannot handle is drawn in software.

  • Raster primitives are always available: the GPU accelerates the operations it implements (it may fill rectangles but not draw lines, for instance), and the engine renders the rest in software. A raster operation never fails for lack of GPU support; at worst it is slower.

  • Vector graphics are not always available: MicroVG requires a vector GPU (VGLite or NemaVG) and has no software implementation of the vector layer in the engine. A VEE Port that lacks vector support does not render vectors slowly; it does not render them at all, and this happens in one of two ways. If the VEE Port does not provide the MicroVG foundation library, the application does not build against it. If the library is present but the vector drawing is not implemented, a drawing primitive is a no-op at runtime (nothing is drawn) and reports a NOT_IMPLEMENTED drawing error at the next flush().

Before designing any part of the UI around MicroVG (scalable vector icons, animated vector graphics, vector fonts), confirm that the VEE Port provides it (the VG Pack and a vector GPU); otherwise that part of the UI must be planned in raster.

Note

Do not take the Simulator as proof of embedded support: MicroVG runs on the Simulator only when the VEE Port includes the VG Pack, and the Simulator then simulates a vector GPU (VGLite by default, NemaVG if configured), so vectors can render correctly in simulation even when the embedded BSP provides no vector GPU.

Deciding Per Element

The strategy is chosen separately for each piece of content; the three can be mixed freely on the same screen.

  • Fixed content, or a small finite set of states : use a raster image. Cheapest to draw (a copy or blit). It costs flash, and one image is one size and one orientation.

  • Simple runtime geometry (a few lines, rectangles, a plain progress arc) : use MicroUI raster primitives. Low footprint, computed each frame.

  • Content that must scale to arbitrary sizes, animate transforms, or render with anti-aliased vector quality : use MicroVG, if the VEE Port has a vector GPU. One vector asset stays crisp at every size and is cheap to re-transform with a Matrix. When the alternative is shipping the same image at many sizes or orientations, vector is the footprint win too. The supported vector source formats and their limits are described in Vector Images and the AVD Loader.

Raster Formats and GPU Acceleration

For raster images, which formats a GPU can hardware-accelerate is a property of the board’s GPU, and so is specific to each VEE Port: one GPU may accelerate RGB565 but not ARGB1555, for instance. A format the GPU cannot draw does not error for raster: it silently falls back to software (slower). The accelerated formats are therefore best confirmed against the target VEE Port rather than assumed. The formats each GPU C module accelerates are listed in the MicroUI C modules.

Raster Image Transforms

Rotating or scaling a raster image smoothly is a frequent need (a spinning logo, a pinch-zoom). The public API is TransformPainter (in the Drawing API module, ej.api:drawing):

  • drawRotatedImageBilinear / drawRotatedImageNearestNeighbor : free-angle rotation around a centre.

  • drawScaledImageBilinear / drawScaledImageNearestNeighbor : scaling.

  • drawFlippedImage : one of the eight 90° orientations (0°, 90°, 180°, or 270°, each with or without mirroring).

Bilinear is smoother (anti-aliased) and costlier than nearest-neighbor. The key caveat: these transforms are hardware-accelerated only if the VEE Port implements the corresponding optional drawing entries for its GPU. Where it does, rotation and scaling are cheap; where it does not, they run in software, and a continuous full-image rotation in software is a per-frame CPU cost that will not hold a smooth frame rate. Because this varies from one board to another, the target VEE Port’s rotation and scaling capability is worth establishing before a UI relies on smooth image transforms. The operations each GPU C module accelerates are listed in the MicroUI C modules.

On a board that has no such hardware, a continuously animated image has no satisfying raster solution: a pre-rendered sprite sheet of 360 rotation frames is heavy on flash and quantizes the angles, and a per-pixel CPU rotation cannot sustain the frame rate. A board with a vector GPU offers a better route for a complex, continuously transformed visual: authoring it as a VectorImage drawn with VectorGraphicsPainter and a Matrix, where the transforms are hardware-accelerated and stay crisp at any size or angle.