Meego Wiki
Views

User:Jketreno/scaling

From MeeGo wiki
< User:Jketreno(Difference between revisions)
Jump to: navigation, search
(thoughts on asset theme scaling)
(images)
 
(4 intermediate revisions not shown)
Line 39: Line 39:
=Implementation Details=
=Implementation Details=
==Getting the code==
==Getting the code==
-
  git clone '''todo -- where is the code repository???'''
+
MeeGo Units are now available in the MeeGo.Components project.
-
  cd meego-units
+
  git clone git://meego.gitorious.org/meego-ux/meego-ux-components
 +
  cd meego-ux-components
  qmake
  qmake
  make && sudo make install
  make && sudo make install
==accessing the units==
==accessing the units==
-
To start, you need to import the MeeGo Units plug-in:
+
To start, you need to import the MeeGo Components:
  import Qt 4.7
  import Qt 4.7
-
  import MeeGo.units 1.0
+
  import MeeGo.Components 0.1
-
This loads the libmeegounitsplugin adds a new QML type called 'MeeGoUnits'  Since plug-ins do not have direct access to the global object namespace, the plug-in can't automatically populate a top level namespace with a 'Units' element--so you must instantiate it within your top level widget:
+
You can then instantiate and reference the Units:
  Rectangle {
  Rectangle {
-
     MeeGoUnits {
+
     Units { id: units }
-
          id: units
+
-
    }
+
  }
  }
-
At this point, you can now reference the unit conversion properties via '''units'''.  The properties exposed are '''mm''', '''inch''', '''vp''', and '''density'''.  All three are implemented as properties with notification signals, so if the underlying device PPI changes, all UI elements can be re-laid out.  This is useful when moving (at run-time) an application from a small handset screen to a larger display (for example via an attached HDMI)
+
At this point, you can now reference the unit conversion properties via '''units'''.  
-
 
+
==Methods==
-
Extending the above example to set the rectangle size to be 10cm x 5cm:
+
  int mm2px(real millimeters)
-
Rectangle {
+
int inch2px(real inches)
-
    MeeGoUnits {
+
int vp2px(real virtualPixels)
-
          id: units
+
==Properties==
-
    }
+
property real '''mm'''   // Pixels per millimeter
-
    width: units.mm2px(100.0)
+
property real '''inch''' // Pixels per inch
-
    height: units.mm2px(50.0)
+
property real '''vp'''   // Pixels per "virtual-pixel"
-
}
+
====a note on rounding====
-
Using the conversion properties is pretty straight forward and works as you would expect.  The following instantiates a 1cm x 1cm rectangle, offset from the top left of its parent by 1cm:
+
Since the value of the properties returned by Units are non-integer (for example, units.mm might be '3.66667'), the result of most operations with the units will result in non-integer numbers as well.  Due to the cast of real to int, you may encounter rounding problems which typically manifest themselves as QML Items not always lining up.  This can be remedied by using the mm2px() methods exposed by the units object vs. using units.mm directly.
-
    Rectangle {
+
-
        x: units.mm2px(10.0)
+
-
        y: units.mm2px(10.0)
+
-
        width: units.mm2px(10.0)
+
-
        height: units.mm2px(10.0)
+
-
    }
+
-
 
+
-
==a note on rounding==
+
-
Since the value of the properties returned by MeeGoUnits are non-integer (for example, units.mm might be '3.66667'), the result of most operations with the units will result in non-integer numbers as well.  Due to the cast of real to int, you may encounter rounding problems which typically manifest themselves as QML Items not always lining up.  This can be remedied by using the mm2px() conversion method exposed by the units object vs. using units.mm directly.
+
The following shows a simplified example which can lead to rounding problems:
The following shows a simplified example which can lead to rounding problems:
Line 86: Line 76:
     ...
     ...
  }
  }
-
 
+
==Examples==
 +
Create a 10cm x 5cm box:
 +
Rectangle {
 +
    Units { id: units }
 +
    width: units.mm2px(100.0)
 +
    height: units.mm2px(50.0)
 +
}
==text==
==text==
  Text {
  Text {
Line 92: Line 88:
     text: "2.5mm font"
     text: "2.5mm font"
  }
  }
-
 
==images==
==images==
  Image {
  Image {
 +
    // Since this image will be scaled on many devices,
 +
    // smooth the scaling so the image looks better
 +
    smooth: true
     source: "text-bg.jpg"
     source: "text-bg.jpg"
     width: units.mm2px(9.5)
     width: units.mm2px(9.5)
     height: units.mm2px(6.0)
     height: units.mm2px(6.0)
-
    sourceSize.width: units.mm2px(9.5)
 
-
    sourceSize.height: units.mm2px(6.0)
 
  }
  }
-
 
+
<!--....
-
===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"
+
-
    *
+
-
 
+
-
BorderImage {
+
-
    width: 1024
+
-
    height: 768
+
-
    source: "image://super{/dimensions{/units}}/resource{.ext}"
+
-
    source: "image://super/" + width + "x" + height + "/px/resource"
+
-
    source: theme.avatar.source
+
-
}
+
-
 
+
-
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.avatarWidth <--- 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 : */
+
-
 
+
==vector vs. raster==
==vector vs. raster==
==naming conventions==
==naming conventions==
==resource sharing==
==resource sharing==
==scaling==
==scaling==
-
<!--....
 
The software automatically adjusts and scales the UI elements and assets to account for varying physical sizes and PPIs.  A typical problem with automatic system rescaling of images and UI widgets is that the resulting scaled interface may not look ideal.  In the event there is a popular product category that an application creator wants to target, the system provides a mechanism for the creator to provide PPI specific assets which will override the system scaling and be used for those target PPIs.  The approach used is similar to mip-mapping of textures in 3D applications, where the application creator can provide a myriad of target resolutions and PPIs and the software will interpolate between the nearest PPI and size versions to create new sizes and versions as needed.
The software automatically adjusts and scales the UI elements and assets to account for varying physical sizes and PPIs.  A typical problem with automatic system rescaling of images and UI widgets is that the resulting scaled interface may not look ideal.  In the event there is a popular product category that an application creator wants to target, the system provides a mechanism for the creator to provide PPI specific assets which will override the system scaling and be used for those target PPIs.  The approach used is similar to mip-mapping of textures in 3D applications, where the application creator can provide a myriad of target resolutions and PPIs and the software will interpolate between the nearest PPI and size versions to create new sizes and versions as needed.
...-->
...-->

Latest revision as of 19:03, 6 May 2011

THIS PAGE IS A WORK IN PROGRESS AND DOES NOT NECESSARILY CORRESPOND TO CURRENT REALITY

Contents

Introduction

This document provides an overview of how applications can be written to support the broadest range of physical screen characteristics with the least amount of work by the application authors and graphic designers.

The intent is to provide a means of allowing applications to be written in a density independent manner, where the physical size of UI elements is consistent across a wide spectrum of devices. As automatic software scaling and conversion can not know the internal meaning of a graphics element (which pixels are important), pixel based assets must be designed for the lowest targeted pixels-per-inch (PPI). In this manner, system software can scale up to the actual device pixel density.

By following the guidelines in this document, application creators can create a single application package which will work across all devices, varying both in pixel density and physical screen sizes.

Lower priority: In addition to the varying densities targeted by MeeGo, the system should support various "distance-from-eye" scenarios as well as varying "input device resolution". An example of the former is a status bar on a tablet that is held 6-8" farther from the eyes than a handset--this may require that the status bar and fonts are slightly larger to maintain legibility. This may be achieved by providing a readability scaling factor used elements not intended to be manipulated via touch. An example of the later (varying input device resolution) is a scaling factor applied to the specified physical size of an element to accommodate higher precision devices (mice and stylus) as well as lower precision devices (gyro/accelerometer remotes, thumb-stick remotes, etc.)

Target Resolutions and PPI

The following image illustrates a small application running across the full range of screen sizes and densities currently supported by MeeGo. These images have been scaled to provide consistent relative sizing in the image. This was done by converting 1:1 pixel images to a virtual pixel density of 160ppi. Click the image to go to the higher resolution version.

Density Independent Rendered Sample

A small 1:1 pixel crop from the highest density display (269ppi) and the lowest density (113ppi) can be seen here. When placed on the actual devices, the toolbar, buttons, and fonts would be physically the same size.

1:1 Pixel Comparison

As can be seen in the table below, touch enabled MeeGo user experiences target two major physical screen size classifications; tablet (>7") and handset (~4"). In addition to the varying physical dimensions of the screens, the devices have various PPIs [dots-per-inch -- also referred to as PPI or pixels-per-inch]. Based on the expected frequency of deployment, we are focusing our "pixel perfect" UIs for only a select set of DPIs and screen resolutions.

Current Device Resolutions

The following provides examples of potential screen profiles which should be supported by MeeGo:

Handset
DiagonalResolutionPPIAspect Ratio
4"800x48023315:9
4.3"960x54025616:9
3.67"864x48026916.2:9
Tablet
DiagonalResolutionPPIAspect Ratio
10"1024x60011915.4:9
10"1024x60011915.4:9
11.6"1360x76813516:9
10"1280x80015116:10
7"1280x80021616:10

Industry list of display densities

Implementation Details

Getting the code

MeeGo Units are now available in the MeeGo.Components project.

git clone git://meego.gitorious.org/meego-ux/meego-ux-components
cd meego-ux-components
qmake
make && sudo make install

accessing the units

To start, you need to import the MeeGo Components:

import Qt 4.7
import MeeGo.Components 0.1

You can then instantiate and reference the Units:

Rectangle {
    Units { id: units }
}

At this point, you can now reference the unit conversion properties via units.

Methods

int mm2px(real millimeters)
int inch2px(real inches)
int vp2px(real virtualPixels)

Properties

property real mm   // Pixels per millimeter
property real inch // Pixels per inch
property real vp   // Pixels per "virtual-pixel"

a note on rounding

Since the value of the properties returned by Units are non-integer (for example, units.mm might be '3.66667'), the result of most operations with the units will result in non-integer numbers as well. Due to the cast of real to int, you may encounter rounding problems which typically manifest themselves as QML Items not always lining up. This can be remedied by using the mm2px() methods exposed by the units object vs. using units.mm directly.

The following shows a simplified example which can lead to rounding problems:

Rectangle {
   width: 20.0 * units.mm
   height: 10.0 * units.mm
   ...
}

Better code:

Rectangle {
   width: units.mm2px(20.0)
   height: units.mm2px(10.0)
   ...
}

Examples

Create a 10cm x 5cm box:

Rectangle {
    Units { id: units }
    width: units.mm2px(100.0)
    height: units.mm2px(50.0)
}

text

Text {
   font.pixelSize: units.mm2px(2.5) // create text that is 2.5mm tall
   text: "2.5mm font"
}

images

Image {
    // Since this image will be scaled on many devices, 
    // smooth the scaling so the image looks better
    smooth: true 
    source: "text-bg.jpg"
    width: units.mm2px(9.5)
    height: units.mm2px(6.0)
}
Personal tools