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.