Views
User:Jketreno/theme-assets
THIS PAGE IS A WORK IN PROGRESS AND DOES NOT NECESSARILY CORRESPOND TO CURRENT REALITY
Contents |
Introduction
The assets used in the visual design of our applications can be broken down into categories:
- Icons assets
- Non-Icon assets
Icons are typically fixed size and connote a contextual meaning. Non-icon assets are used as graphical filler; they provide the backgrounds, borders, and color but do not add any specific meaning.
This document covers the methodology and work-flow used by MeeGo to order to provide the highest quality visual experience on a broad spectrum of devices while developing icons and non-icon assets.
It is assumed that the reader is familiar with Density Independence. For a general overview of that topic, see Density Independence.
Graphical Theme Assets Details
Pixel vs. Vector
There are two formats in which graphical assets can be provided for MeeGo: pixel and vector.
Pixel (sometimes referred to as raster) assets specify the ARGB color values of each individual pixel. The quality of what the user sees on their display is heavily dependent on the display density for which the graphical asset was designed. When designed for a 300DPI screen, an icon intended to be one 1/2" x 1/2" will need to be 150x150 pixels. When viewed on a 150DPI screen, in order to maintain the same physical size, the asset will need to be scaled down by 50%. The MeeGo theming image provider will perform this scaling for applications, using a smooth scaling algorithm to reduce artifacts. Designing for a high DPI and scaling down is the recommended technique for pixel based graphics.
Vector (sometimes referred to as scalable) assets are specified by paths defined by mathematical equations and are effectively resolution independent which means they can be rasterized at varying densities and sizes without introducing scaling artifacts.
Virtual Pixel
As vector graphics are density independent, there needs to be a way to map the units used within the vector graphic to physical pixels during rasterization. MeeGo accomplishes this by using a default virtual density of 330 pixels per inch for vector graphics. This allows the vector graphic to use any real world unit of measure desired while allowing Border Images (which may be relative to the rasterized vector graphic) to be specified in a density independent manner.
Recommended usages for pixel and vector assets
Icons, which are typically only scaled to maintain a consistent physical size on the display (for example a button icon which should always be 8mm x 8mm, regardless of the device DPI) should be provided as a pixel asset. If the asset is designed for a high density display, there will be minimal artifacts when scaled down to lower density displays. MeeGo will automatically scale pixel assets to new sizes as needed. See the section on Dynamic Asset Scaling for details on how this is accomplished.
Non-icon assets, which may be arbitrarily scaled in X and Y dimension, are best provided as a vector graphic. This is to reduce banding and aliasing artifacts which would typically occur in gradients, drop shadows, and other effects.
MeeGo provides a caching mechanism to alleviate the cost of rasterizing a vector asset.
Downscaling Example
The following example illustrates a possible pitfall if fine line details are used when drawing pixel graphics at higher DPI screens
Above illustrates scaling of a pixel asset from 330DPI to various DPIs.
Upscaling Example
The effect of upscaling a pixel vs. vector asset is shown here:
In the above example the 32x32 red circle, with a one pixel border, was scaled to be four times larger. Applying a cubic filter helps to reduce aliasing but muddies the result.
The vector asset is very clean at the new target size.
There are a few reasons why vector graphics are not used everywhere:
- Time -- Some artistic techniques are difficult to express in terms of paths, fills, and filters. Requiring all assets to always be provided in a scalable form places undo restrictions on the graphic designer.
- Compatibility -- some paths, fills, and filters do not produce the same results in the tools building them and the software used in MeeGo to rasterize the asset.
Dynamic Asset Scaling
todo Describe the logic flow for pixel asset priority, vector priority, scaling, interleaving, etc.
Icon Assets
Editing and naming conventions
Icons for MeeGo have two states:
- normal
- active
Providing a separate for each state is error prone and inefficient. For designers, it requires that multiple files be opened and managed visually which makes quick changes and uniformity more difficult. For loading efficiency, the more files that have to be opened and read, the slower the system behaves.
To improve on this, MeeGo icons provide both states in a single graphical asset. QML elements which use the Icons for button states rely on other means (background colors, alpha overlays, etc.) to provide additional state visualizations (mainly selected and disabled.)
Eventually MeeGo will provide an icon tile management layer to preload all rasterized assets into a large texture set which can be loaded once and then sliced at run-time.
Pixel based assets
For pixel based icon assets the following naming convention is used:
icon-NAME-multistate.EXTENSION
Where:
- NAME is the icon name, for example "close"
- EXTENSION is one of the recognized image extensions. While the system supports both PNG and JPG, it is recommended that only PNG be used.
In terms of a regular expression, the above maps to:
icon-[[:alnum:]]+multistate.(png|jpg)
The graphical asset is laid out internally such that the pixel width of the individual icon is the width of the total asset divided by two.. For example:
The above file (icon-close-multistate.png) provides a 120x50 pixel icon asset. Each icon is then 60x50 pixels.
Scalable assets
For scalable icon assets, the naming convention is much simpler:
icon-NAME-multistate.svg
Where:
- NAME is the icon name, for example "back"
MeeGo will parse the SVG looking for three top level groups with the following names:
- normal
- active
Non-Icon Assets
Non-Icon assets (such as button backgrounds, borders, drop shadows)
Border Images
When a non-icon asset is used as an element background image, it is scaled to fill the entire element. The scaling is applied uniformly across the entire asset. For assets that contain a border, this uniform scaling is not what is typically desired. MeeGo provides a mechanism for the asset designer to specify the region of the graphical element that should be stretched and the region which should not be scaled. These types of graphic assets are referred to as a "Border Image"
In the above image, a 4 pixel border is provided on all sides. When scaled to arbitrary sizes, scaling is only applied to non-border portions:
Border Image Specification
Two approaches:
- Per-asset .sci file provided which contains the border widths. For example:
$ cat background.sci border.left: 5 border.right: 5 border.top: 5 border.bottom: 5 source:background.png
- Per-directory .sci file. For example:
$ cat index.sci # Format: # image-source top right bottom left background.png 5 5 5 5 foreground.png 10 2 10 2
To refrence background.png with the border image properties, QML would refer to the virtual asset background.png.sci.
If both an index.sci and a separate asset .sci file are provided, the separate file will override the index.sci.
Border Image: Pixel vs. Vector
Image slicing for pixel assets are specified in pixels which means the border element is not scaled relative to the screen pixel density. The measurable size of a border on a high density display will be smaller than a display with a lower density.
With vector assets, the border size is specified in a virtual pixel representing 330 pixels per inch. This allows MeeGo to scale the border region proportional with the display density, ensuring a uniform look across multiple display profiles.
thoughts on asset theme scaling
/* Not done yet -- auto scaling and caching from an asset daemon with target size scaling:
*
* source: "image://" + unit + "/" + w + "x" + h "/text-bg"
*
// Every image used could be a BorderImage
BorderImage {
width: 1024
height: 768
source: "image://super[/dimensions[/units]]/resource[.ext]" <-- Optional extension to override the default priority ordering
source: "image://super/100x75/resource" <-- width is 100 pixels, height 75 pixels
source: "image://super/2.5x2.0/mm/resource" <-- width is 2.5 millimeters, height is 2.0 millimeters
source: theme.avatar.source <-- width and height is specified by the theme
}
theme.avatar contains:
{
width <--- In pixels
height <--- In pixels
source <--- Uses the uber theme image provider
}
width: 20 <--- hard coded, non density independent width: mm2px(5) <---hard coded, density independent width: theme.avatar.width <--- theme over-ridable, density independent
supporting the scaled size of the border in a border image via the theme; probably requires creating a new "borderimage" replacement that supports a set of target border size properties. Usage example is to take a 1px border from a pixel asset and have the border actually scaled to 2mm on the display
*
* So, instead, set the source width and height to the scaled dimensions : */
MeeGo Theming Specifics
Directory structure
Naming conventions
Installation process
Tile cache
MeeGo Theming in Applications
MeeGo.Components
Density Independence
Fonts
MeeGo Image Providers
todo describe how and where assets are placed into the distribution, how they are rasterized, where cached assets are stored, how tile caches are built, and how the image loaders tie it all together...
Tool compatibility
Graphic designers use a variety of tools, depending on personal preference and the task at hand. Not all features exposed by some tools are compatible with other tools, or with the infrastructure used on MeeGo for extracting and managing visual assets. This section is intended to call out known compatibility issues and work arounds.