Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

If you would repeat the experiment multiple times, you will notice
that the 2% below is even below the error margin. So I am very
doubtful there is any improvement at all :-)

And about the memcpy: I am pretty sure you will bump into
synchronization issues between two event loops (one of phoneme
and one of the Qt4 frontend). The phoneME backend calls a
method in the Qt4 frontend to say it is time to paint the buffer. The
Qt4 front-end will emit an asynchronous signal. By the time this
signal is processed the original buffer has changed, resulting in
flickering and painting of intermediate frames if you use the
original buffer.

But feel free to experiment, you never know ... :-)

Davy

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

JBenchmark:

http://davy.preuveneers.be/phoneme/p...mo/jbenchmark/

Note: only JBenchmark and JBenchmark2 work. The others require
more JSR support

Davy

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

No way this could be swallowed by autobuilder :(. The only way it can be pushed is by binary distribution.

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

Thanks a lot.

OK, second optimization pass (memcpy is gone), JBenchmark2 result(same conditions)

landscape - 972
portrait - 804

going to try your benchmarks, will post theresults here.

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

Nice! And no flickering?

Davy

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

actually your libcvm.so build is set-up to use double-buffering :p

so... no flickering ;)

EDIT:
But anyway I will add some synchronization, just in case, it could lower the results a bit, but will make sure there will be no flicker under any conditions

EDIT2:
with DavyP's benchmarks:

JBenchmark, landscape only (seems does not like portrait) - 5845

JBenchmark2:
landscape - 978
portrait - 906

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

Another remark:

It is possible that the above results are not accurate for another reason. The performance results are measured based on what happens in the event loop of phoneME. This event loop triggers in the Qt4 front-end app a signal emit. So most of what you measure is computation related, not screen IO related. The actual repainting is done in the event-loop of the Qt4 front-end, and it is possible that in this event-loop multiple repaint events are coalesced into a single one (i.e. a single screen update). So the actual painting time in the Qt4 event loop is not included in the benchmark, and the actual screen updates could be lower than what you measure.

Davy

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

But the same could happen with your code, i.e. there is no check if the current buffer has been painted before doing memcpy over it. And it is less possible to happen without memcpy, as there are 2 screens buffers used by libcvm, against just 1 when memcpy is used. Anyway, i will implement some buffer synchronization, I promise :).

On the other hand both threads are CPU bound, so when there is less overhead (because there is no memcpy for every screen buffer), the computational thread is given more CPU shares to do its job, so I believe the benchmark results are pretty corect.

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

True. I don't check before the memcpy either as I don't want to force paint every frame either if the device cannot keep up.

Anyway, I don't want to discourage you in any way. The only point I wanted to make is that I am always careful with interpreting benchmarks, especially if I don't know what they are measuring :-),
but any frame rate improvement you can squeeze out of it would be most welcome.

Cheers,
Davy

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

So without memcpy it is better because of the 2 buffers.

Well, I am not the one who would understand conversation like that as discouraging. Not that I could be discouraged easy :D . And yes, bencmarks could be pretty misleading, I fully agree with you, but while we lack a better tools, we have to stick to what we have :)

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

First things first, thanks so much for everything.
We have whatever phone parts you can imagine on sell in China. I had fun changing my n900 screen once. And digitizer plus frame like this (titled"original n900 outer screen", price is 85CNY, roughly 8 euro) can be easily bought and mostly reliable (I can't guarantee they are 100% original though). If you have friends traveling in china, I can send them the part. Sending by mail is also possible but might be slow and a bit expensive.

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

@DavyP

OK, buffer synchronization added, the results(same conditions as in previous runs):

JBenchmark - 3400 :o

JBenchmark2:
landscape - 1002
portrait - 920

After all there WERE multiple repaint events coalesced into a single one for JBenchmark :) , anyway, everything is fine now. What I did not expect is higher result for JBenchmark2 :confused:

Later today I will try to upload cvm code on gitorious, so you can look into it and run the benchmarks on your own if you wish. Just have in mind that my libcvm is compiled with -mvfp, -mcortex-a8 and export CVM_ARM_HAS_WMMX=true, so your result might be a little bit lower because of missing those optimizations . I suspect my cvm won't work correctly on Harmattan (as I removed pixmap rotation), but that could be easily fixed by using appropriate #ifdefs

I wonder if using QML or GLES will speed rendering. But as for now a speedup of 16% for landscape and 21% for portrait seems enough.

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

Unrelated to the technical discussion but relevant for Opera Mini users.. I'm curious to see if others are having the same problem.

As of last night Opera Mini v6.5 stopped downloading pages. Network test showed I had a working connection on WiFi or 2G.
I had a look around for other versions to try, found the official OM v4.4 - same issue since it is a new browser.

I tried downloading the Handler versions so I could try different servers or direct to the OM4 servers instead - still won't work since it detects the version of Mini you are running.


Only working versions at the moment are v4.2, and V5 (which I am using for the moment).

EDIT: V6 is working

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

I have no problem with Opera Mini 6.5.

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

Which cross-compiler are you using?

/scratchbox/compilers/cs2007q3-glibc2.5-arm7/bin/arm-none-linux-gnueabi-gcc does not like the -mvfp -mcortex-a8 command
line options.

Davy

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

Yep, the same. Find attached my build scripts.

Going to upload cvm sources on gitorious.

EDIT:

cvm sources here

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

I have the same issue, but a few release back, Opera Mini start in portrait mode and you can choose landscape mode on the settings. Unfortunately I don't remember, what was the last release, the OM works great (except auto-rotation).

Thanks for your work.

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

If you are willing to try which build worked for you before, I can
have a shot at figuring out which change broke portrait mode for
Opera Mini. Here you can find some old builds:

http://davy.preuveneers.be/phoneme/public/maemo/deb/

Also, since installation settings of Opera Mini remain after
reinstalling a different deb, it might be a good idea to clean the
/opt/phoneme directory.

Davy

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

Ok, today I will test it.

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

I tested it. The march 7 release had good Opera Mini orientation, but the march 8 had not.

I check the march 7 release. Sound was good, but didn't find the location.jad to check the GPS.

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

Thanks for testing! The location feature was added afterwards, so that is normal.

Just to be sure: you did install the MeeGo builds and not the Maemo builds right?

The reason why I ask is because I checked the source of 2 backups of March 5 and March 11, and I added a.o. a rotation feature:

#ifdef Q_WS_MAEMO_5
setAttribute(Qt::WA_Maemo5AutoOrientation, true);
setAttribute(Qt::WA_Maemo5NonComposited);
#endif

However, due to the ifdef macro, this code is excluded for the MeeGo builds (presuming you did not install the Maemo build on your MeeGo device).

Another change is the fact I added multimedia and location features that rely on the Qt Mobility libraries. So I may have to produce a few test builds to really identify which change caused the portrait mode issue.

Davy

I installed the MeeGo one. Thanks for your work, I hope you'll find the problem.

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

Nimbuzz working on N900 !!!

http://talk.maemo.org/showthread.php...hlight=nimbuzz

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

Whenever i chose http as proxy server on opera mini 6.5 it doesn't work.why

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

I can't run Nimbuzz , the app doesn't open when I use run MIDlet , it opens a white screen then close in a half of second . Same on N900

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

Can I ask you another favor? I am not entirely sure the dates of the builds I put online before match with the dates of the backups (some local changes may only got integrated in a build I uploaded days after). Could you test the following builds again:

http://davy.preuveneers.be/phoneme/p...aemo/deb/test/

These do not match with the ones you tested earlier as I recompiled them again. However, this time I made sure I have the matching build configuration files and sources, which should help me to hopefully find the cause of the orientation problem.

Thanks,
Davy

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

Hi DavyP,

Are you considering to optify (move the stuff out of rootfs) the application?. Actually 4 Mbs is way too much and I had to uninstall it to be able to update to latest CSSU.

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

it has already optified, try latest build.

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

I tested the 7th, the 8th, the 11th neither of them was good (both started in landscape mode) and the 6th version was good.

I hoped that will help you.

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

I want to play the game "Di tim trieu phu" (Milionaire), but could not. I can not help. Thank's

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

Thanks,

The code changes between the 6th and the 7th were not that significant, except for the fact that I changed some command line parameters, i.e. "portrait" and "noportrait" became "rotate" and "norotate" respectively.

If you used "-portrait" in some startup scripts, then this may explain this change in behavior. I changed the naming, because if you enabled the old portrait option and if your display was already in portrait mode, then the midlet would be shown in landscape mode rather than portrait mode.

I created a new build in which I add the old command line parameters again, and mapped them on the new ones (portrait -> rotate, and noportrait -> norotate).

I uploaded a new test build at http://davy.preuveneers.be/phoneme/p...aemo/deb/test/

You can also check the default rotate/portrait behavior in the MIDlet Settings application.

Cheers,
Davy

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

I don't have the sources to Opera Mini to figure out what it is trying to do, so I am afraid I cannot help you with this one.

Davy

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

Nice to hear that it works (although I am not a Nimbuzz user myself).

Davy

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

@DavyP - did you look at cvm code I pushed on gitorious and my build scripts?

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

Yes, but I have not come around to integrate your changes into my build.

I noticed that you removed the static buffer in which I copied all the pixels from the original framebuffer pointer when phoneME tells me to draw the buffer. My code relied on this buffer when I emited a Qt4 signal to draw the buffer.

You pass along the original pointer directly to the Qt4 front-end. Using the original pointer is a bit dangerous. By the time the refresh signal gets processed and the buffer gets painted, the contents and the size of the original framebuffer pointer may have changed, causing bad repaints or even segmentation faults. This has to do with the inner workings of phoneME, and the asynchronous handling of Qt4 signals.

Before, I actually implemented it more or less the way you did it (without the static buffer), and I got segmentation crashes when I was playing some animation (continuous repaints) while changing the display size (going full screen).

I will first do some testing to see whether your code suffers from the same problem before integrating your changes in my latest code.

Cheers,
Davy

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

Hmm, but I actually don't allow phoneME to draw to a buffer which is still in use by Qt. Have in mind that we have TWO buffers used in sequence. And there is a (lame) spinlock protecting currently used buffer, look

here: https://gitorious.org/cvm-qt/cvm/blo...in.cpp#line139

and here: https://gitorious.org/cvm-qt/cvm/blo...er.cpp#line162

That way when a new buffer needs to be painted, we don't return control to PhoneME until the old one is still painted by Qt, preventing PhoneME from using it ;). Sure, this synchronization could be implemented without the overhead of using QMap, but as POC it should be good enough.

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

You are right. I did not notice the usleep() you use to synchronize between both event loops. You indeed do not need a QMap to synchronize (a dirty flag will do). The pointer passed along to repaintPixmap() is often the same anyhow.

Also, I wonder if you could speed things up by waiting a bit longer than usleep(1), i.e. 1 microsecond. I don't know how fine-grained the N900's default timer resolution is, but if it would be that accurate, you are spending a lot of CPU with busy waiting. I think somewhere between 1 to 10 milliseconds (or 1000 to 10000 microseconds) might improves things as you sleep longer per iteration, leaving more time for the other threads to complete the repainting. I have not tested this though, as you would have to count how often you execute the cycle in a benchmark setup (where you try to paint as fast as possible).

Cheers,
Davy

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

Absolutely, it could be optimized further, but as I told you that was just a POC and I was lazy to use/implement atomic integer operations or to read through the net if operations on u32 type are atomic on ARM7 :o .

Disagree, framebuffer frontend uses backbuffering, i.e. two buffers used for consecutive painting. BTW i had put some qDebug() in repaintPixmap and can assure you, that those two buffers are rotated, i.e. you never have one and the same pointer for two consecutive repaintPixmap calls.

Yeah, I was thinking the same, a proposed delay should be pretty enough.

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

Happy easter, sorry for the ******!
Anyway, Davy Nimbuzz doesnt work. It's not fully supported by your JVM becouse it needs to be maybe remapped?! Anyway... I have a problem with the Facebook app. The new facebook app has to store some data, but this version doesnt, becouse of the vm maybe, it doesnt save username and password. In the error log, there's not nothing about this kind of problem,this is the Facebook official APP, can you make something to fix this error? i add the Jar file down here... Thx 1000

Cristian

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

I tested, but the problem is there. OM starts in landscape mode.