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 <[email protected]> wrote: > On Sun, Jan 23, 2011 at 1:22 PM, Jan <[email protected]> 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 > [email protected] > http://lists.qt.nokia.com/mailman/listinfo/qt-qml >
_______________________________________________ Qt-qml mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt-qml
