Hi,

many of us here develop applications for mobile devices with varying levels of success.
there are a few key elements which should go together to produce excellent applications within our constrained environment.

liqbase makes use of all of these and manages to produce lightweight extremely responsive applications ( see here for progress: http://www.youtube.com/watch?v=vt7qB37sLLo )

however you don't necessarily need to change the toolkit you are currently using to obtain good looking results.

On the desktop whether using GTK or QT I doubt anybody concerns themselves with the number of drawn layers in an application, the graphics cards there manage to render many many more frames than we can make use of.

On the tablets (obviously..) things are a little more constrained - even when the new device(s?) come along maintaining a heavily optimized application helps your battery.
even in the best case scenario your little computer will be held up by drawing and redrawing all these intermediate layers.
If you can cut back on the number of painted items and redundant refreshes then you can gain realistically visible improvements in performance.
think about back panels and containers within containers and make sure you disable painting of areas already pre-painted by the container.

Cutting down on the amount of UI clutter in your applications obviously helps to make a usable clean interface.
The principles of optimization are universal no matter what application you are writing and whatever toolkit you are using.
for instance, I discovered one of the best articles about optimization and simplicity from reading the forum nokia site and finding an article relating to WRT widgets:

http://blogs.forum.nokia.com/blog/al...lopment-part-2

so, let me know - what tips and advice would you give to prospective app developers?


(*apologies for formatting, hastily pasted from notes i made lastnight)

Wow, great topic, but a big topic.

I would suggest staying away from Qt for the time being. Although the current Qt armel implementation (4.3?) seems very robust, it's noticeably less responsive than GTK. To reiterate, that's just for the time being.

Good subject Gary.

As a day job I work with embedded devices, hell, my first commercial device I sold, and sold 100,000+ units of, had 512k of programmable space, which, believe it or not we rarely filled.

I think common sense prevails. If your restricted for space, use shorts instead of int's if you can, if you can cut down on code by modularizing it the do it (reuse is a big win all round), always look to do code in a more efficient (but readable!) way even if the code works already.

I probably should look at the code to liqbase and see if I can give you some pointers

can I ask, why is that only for the time being?

is qt actually faster than gtk?

As someone who uses Qt on a daily basis and has dabbled with GTK in the past, I'd concur GTK is quicker on today's NITs as Qt optimizations are just starting to appear, and I'm under the impression Hildon gives Qt quite an overhead (compared to GTK). Also, some of the most powerful embedded Qt features (like the OpenGL ES support) is not applicable because of the lack of drivers or hardware. With those factors potentially eliminated in the next year or so, I'd say it would be a pretty even match, GTK faster in some areas, Qt faster in others.

From what I understand the 'time being' statement is indicative of Nokia's push for QT to be the defacto-standard for cross-platform development. I believe the open-sourcing of QT will bring many improvements and hopefully the perception of QT being a slower brother to GTK will soon become a distance memory.

Nokia has very high hopes for Qt 4.5 and mobile devices. I think you of all people will find this article significant. A tidbit:

ok daperl,

those sound like serious improvements coming down the line which should allow qt applications to catchup to current GTK apps.

but the fact remains an optimized QT application will run better than a bloated QT application

if everybody waits for upstream improvements we won't have an optimal experience all round and there has got to be a sensible subset of modifications app developers themselves can follow.

I think we can safely generalize that "the fact remains an optimized insert_toolkit_or_language_here application will run better than a bloated insert_toolkit_or_language_here application"

Sometimes a 0.1sec delay we barely notice on a desktop translates to a 1sec delay on the tablet, so when porting desktop solutions something (certainly optimizable) suddenly makes stuff look slow and clunky. This can happen especially functions heavily reliant on certain Qt optimizations not applicable on a particular platform. Profiling helps a lot, but sometimes a keen eye is more important - to notice the spots that *feel* slow even though they might objectively eat just a few cycles.

lcuk, you lost me a little bit. I throw away code all the time and I port code all the time. I just try to do those things as little as possible.

In general, I try to be platform agnostic, but I have a tendency to go down the tried-and-true path first. The Qt/GTK thing is a fork in the road that I think we have to live with for now.