Notices


Reply
Thread Tools
Posts: 268 | Thanked: 75 times | Joined on Jan 2011
#381
Did you add sound support for the n900?

Because in my game i can not heard anything and sound support still is on your todo list
 
santiago's Avatar
Posts: 518 | Thanked: 334 times | Joined on Mar 2010 @ italy
#382
 
Posts: 3,074 | Thanked: 12,960 times | Joined on Mar 2010 @ Sofia,Bulgaria
#383
@DavyP: There are 2 things you can try to increase performance. Search in Qt documentation for their effect.

First one is Fremantle specific, In your MainWindow constructor (in the same #ifdef..#endif block where WA_Maemo5AutoOrientation lives, place:
Code:
    setAttribute(Qt::WA_Maemo5NonComposited);
that may cause flickering, but I hope that won't happen, as you are double-buffering (AIUI)

Second tweak should work in both Fremantle and Harmattan, in your MainWindow constructor place:
Code:
setAttribute(Qt::WA_OpaquePaintEvent, true);
As you are repainting the whole widget area, there is no need Qt to draw the background first.

BTW I found a bug in your build using WA_Maemo5AutoOrientation:
If you enable "Enable portrait mode" in MIDlet Settings, then window appears rotated 90 degrees (shows landscape when in portrait and vice versa)

Hope the above will help you a bit, thanks a lot for your work, keep it that way
 

The Following 2 Users Say Thank You to freemangordon For This Useful Post:
Posts: 306 | Thanked: 603 times | Joined on Jan 2012 @ Belgium
#384
Originally Posted by Brian_7 View Post
Did you add sound support for the n900?

Because in my game i can not heard anything and sound support still is on your todo list
I only added some hardcoded audio samples for the MIDlet alert
messages. I hope the next steps to play custom samples will be
straightforward. If I also find a nice way to play tones of a particular
frequency and length, then I hope I will have most sound playback
support covered.

Unfortunately, MeeGo does not play ball (as the audio-playback does not seem to work on the N9).

Davy
 

The Following User Says Thank You to DavyP For This Useful Post:
Posts: 306 | Thanked: 603 times | Joined on Jan 2012 @ Belgium
#385
Originally Posted by freemangordon View Post
@DavyP: There are 2 things you can try to increase performance. Search in Qt documentation for their effect.

First one is Fremantle specific, In your MainWindow constructor (in the same #ifdef..#endif block where WA_Maemo5AutoOrientation lives, place:
Code:
    setAttribute(Qt::WA_Maemo5NonComposited);
that may cause flickering, but I hope that won't happen, as you are double-buffering (AIUI)

Second tweak should work in both Fremantle and Harmattan, in your MainWindow constructor place:
Code:
setAttribute(Qt::WA_OpaquePaintEvent, true);
As you are repainting the whole widget area, there is no need Qt to draw the background first.

BTW I found a bug in your build using WA_Maemo5AutoOrientation:
If you enable "Enable portrait mode" in MIDlet Settings, then window appears rotated 90 degrees (shows landscape when in portrait and vice versa)

Hope the above will help you a bit, thanks a lot for your work, keep it that way
Thanks for the suggestions.

About the bug: The "Enable portrait mode" feature is only meant
for devices on which phoneME always starts in landscape mode.
So if auto-rotation works, you should not enable this feature.
With this feature enabled, I actually rotate the midlet 90 degrees.
That is why you are getting the landscape version in portrait mode
and vice versa if auto-rotation works.

Perhaps I should call the feature "Rotate midlet 90 degrees". That
description would be more accurate.

Davy
 
Posts: 306 | Thanked: 603 times | Joined on Jan 2012 @ Belgium
#386
I added the above two tricks and used both JBenchmark and
JBenchmark2 to measure the performance improvement, and I get
overall scores that are up to 8% higher than without the two tricks. Not
world shocking, but a nice improvement nonetheless.

Davy
 

The Following User Says Thank You to DavyP For This Useful Post:
Posts: 3,074 | Thanked: 12,960 times | Joined on Mar 2010 @ Sofia,Bulgaria
#387
Originally Posted by DavyP View Post
I added the above two tricks and used both JBenchmark and
JBenchmark2 to measure the performance improvement, and I get
overall scores that are up to 8% higher than without the two tricks. Not
world shocking, but a nice improvement nonetheless.

Davy
Sounds pretty enough for 2 lines of code . And have in mind those affect only graphics.

EDIT:
non-compositing should have bigger effect in fullscreen

Last edited by freemangordon; 2012-03-07 at 22:26.
 

The Following User Says Thank You to freemangordon For This Useful Post:
Posts: 306 | Thanked: 603 times | Joined on Jan 2012 @ Belgium
#388
Originally Posted by freemangordon View Post
Sounds pretty enough for 2 lines of code . And have in mind those affect only graphics.

EDIT:
non-compositing should have bigger effect in fullscreen
Yes, if I would get an average 5% performance improvement
for every two lines I add, I am willing to add even more lines like that :-)

BTW, I ran the benchmark in full screen. Perhaps to low
improvement is due to the fact I emit a Qt4 signal to trigger for
every midlet window update, and perhaps Qt4 is smart enough to
coalesce repaint events. Also note that the JBenchmarks probably
measure more than just the rendering speed.

Davy
 

The Following 2 Users Say Thank You to DavyP For This Useful Post:
Posts: 3,074 | Thanked: 12,960 times | Joined on Mar 2010 @ Sofia,Bulgaria
#389
Originally Posted by DavyP View Post
Yes, if I would get an average 5% performance improvement
for every two lines I add, I am willing to add even more lines like that :-)

BTW, I ran the benchmark in full screen. Perhaps to low
improvement is due to the fact I emit a Qt4 signal to trigger for
every midlet window update, and perhaps Qt4 is smart enough to
coalesce repaint events. Also note that the JBenchmarks probably
measure more than just the rendering speed.

Davy
I have no idea how is your painting structured, but if you do a full QPixmap paint for every midlet window update, then it might be a good idea to set some clipping when painting the pixmap, that should boost the performance significantly (not that it is slow now, but you know, as Pooh says...)
 

The Following User Says Thank You to freemangordon For This Useful Post:
Posts: 306 | Thanked: 603 times | Joined on Jan 2012 @ Belgium
#390
Originally Posted by freemangordon View Post
I have no idea how is your painting structured, but if you do a full QPixmap paint for every midlet window update, then it might be a good idea to set some clipping when painting the pixmap, that should boost the performance significantly (not that it is slow now, but you know, as Pooh says...)
PhoneME does provide midlet display repaint callbacks with
clipping ranges, but they are usually much bigger than the
bounding box of the pixels that have changed that it usually does
not make much of a difference when painting the full midlet
window or just the area within the clipping ranges.

Especially midlets that paint their own UI on a Canvas or
GameCanvas (like Opera Mini or J2ME Polish/LWUIT midlets),
this definitely does not make much of a difference. This was my
experience on Android, I have not tested this on the N900.

So, for the time being, I think the rendering speed is good enough
so I would rather focus on some more interesting features.

Davy
 
Reply


 
Forum Jump


All times are GMT. The time now is 14:59.