[Qt-qml] Porting without on-device testing

[Gregory Schlomoff]

This is a great piece of advice.

Can someone put this on a wiki or something, so that it won't get lost in
the dephts of the mailing-list archives?

(I would have done it, but I'm unsure of where it should go, and how to do
it)

By the way, is there a reference place for all answers, tutorials, and
advice related to QML? Like the Qt dev network wiki, or something like that?
I never go to those places...


On Mon, Jan 24, 2011 at 4:28 AM, Juha Turunen <turunen at iki.fi> wrote:

> 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
> _______________________________________________
> Qt-qml mailing list
> Qt-qml at qt.nokia.com
> http://lists.qt.nokia.com/mailman/listinfo/qt-qml
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt.nokia.com/pipermail/qt-qml/attachments/20110124/9d127578/attachment.html