Hi, That's very valuable list! One question related to the last bullet still (- Use gradients instead of images if possible. They're faster to draw.) Isn't this just the opposite? Here's a clip from gradient element documentation:
Performance and Limitations Calculating gradients can be computationally expensive compared to the use of solid color fills or images. Consider using gradients for static items in a user interface. In Qt 4.7, only vertical, linear gradients can be applied to items. If you need to apply different orientations of gradients, a combination of rotation and clipping will need to be applied to the relevant items. This can introduce additional performance requirements for your application. The use of animations involving gradient stops may not give the desired result. An alternative way to animate gradients is to use pre-generated images or SVG drawings containing gradients. http://doc.qt.nokia.com/4.7-snapshot/qml-gradient.html#details - Mikko -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of ext Juha Turunen Sent: 23.01.2011 11:29 To: [email protected] Subject: Re: [Qt-qml] Porting without on-device testing 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
