[Qt-qml] Porting without on-device testing

[Juha Turunen]

On Sun, Jan 23, 2011 at 1:22 PM, Jan <jan.maillist at googlemail.com> wrote:
> I know (I watched and enjoyed "ui-design-for-small-screen-devices" video
> yesterday) that you always should test your app on the real target device.
> However, I think I wont buy e.g. N8 in the near future (maybe it is
> possible to rent one for a day).
> Therefore I'd like to ask if those of you who already created an app for
> Symbian3 experienced a lot differences between on-device testing and
> running Qt Creator's simulator.
>
> Maybe it is possible to sum it up in a few rules of a thumb ... e.g.
> "never expect your animation to look as smooth as it does in simulator" etc.

These aren't necessarily differences, but things to keep in mind when
targeting S^3 hardware.

- Never expect I/O (loading images mostly) to be as fast as on
desktop. Preload the necessities on a suitable moment to make sure
they're available right away (this still doesn't resolve the problem
of the images getting uploaded to the GPU on demand). Have the stuff
you need fast on C: drive (yeah it's a scarce resource on the older
hardwares, but not on the new S^3 ones), the eMMC is much slower.
- Don't expect smooth animations if you have defined javascript
expressions that refer to properties that get animated. It's
deceptively easy to define complex bindings. Use anchors whenever
possible.
- On startup, load absolutely minimum amount of QML. Use loaders. If
your first view is complex and requires lots of QML to be parsed, show
a splash screen or something.
- Get rid of transient items when you don't need them anymore. Use
loaders to load such items and set loader's source url to "" when you
don't need the item anymore. If the items contain images they will
compete for space in the image pool of the OpenVG implementation. If
you're likely to need the item soon, at least set the opacity to 0
(this will assure they won't get painted and reuploaded to the GPU
memory if thrown out). Uploading to GPU memory is relatively slow
because of the hardware architecture.
- If possible design the UI wisely so that you don't unnecessarily let
the user fiddle with the UI when some process is running (for example
parsing downloaded data or something) in another thread. I'm not sure
if I've missed something, but I haven't been able to have the UI
completely unaffected by background processing. Or it's just Symbian.
- Design your UI so that the areas reacting to touch are big enough.
It's easy to click a small area with a mouse - not so easy with your
fingers. You don't have to compromise the looks of your UI to achieve
this. Just make the MouseArea bigger than the element visually is if
necessary.
- When designing the color theme and graphics of your app, try to go
to the direction of "washed out" from what looks good on your desktop
LCD. The AMOLED displays reproduce the colors in such candy saturation
that diabetics might get symptoms. Nokia should provide a Photoshop
color profile for proofing the colors on desktop.
- When designing transition animations, try to animate as small area
of the screen as possible. If you need to move 3 elements in a second
try moving each at a time in 300ms. The default QGraphicsView update
mode (or something) is such that it calculates the bounds of items
that need repainting and paints everything inside those bounds. This
can be really bad two little things are animating in opposite corners.
Experiment with the smart update mode (can be slower in some cases
though).
- Use gradients instead of images if possible. They're faster to draw.

I guess it mostly boils down to not to expect the same performance
from the device as you get on the desktop, so constantly testing on
the hardware is essential. If you have a credible demo of your app
and/or a company to back up your story, you could ask Forum Nokia for
a loan device. The cheaper S^3 phones (C7 and C6-01) have the same CPU
and GPU so consider them if they're more in your price range.

Juha