Notices


Reply
Thread Tools
Posts: 306 | Thanked: 603 times | Joined on Jan 2012 @ Belgium
#511
Originally Posted by Arthuro_Adam View Post
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.
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
 
Posts: 306 | Thanked: 603 times | Joined on Jan 2012 @ Belgium
#512
Originally Posted by octave View Post
Whenever i chose http as proxy server on opera mini 6.5 it doesn't work.why
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
 
Posts: 306 | Thanked: 603 times | Joined on Jan 2012 @ Belgium
#513
Originally Posted by demludi View Post
Nimbuzz working on N900 !!!

http://talk.maemo.org/showthread.php...hlight=nimbuzz
Nice to hear that it works (although I am not a Nimbuzz user myself).

Davy
 

The Following User Says Thank You to DavyP For This Useful Post:
Posts: 2,770 | Thanked: 10,978 times | Joined on Mar 2010 @ Sofia,Bulgaria
#514
@DavyP - did you look at cvm code I pushed on gitorious and my build scripts?
 

The Following 2 Users Say Thank You to freemangordon For This Useful Post:
Posts: 306 | Thanked: 603 times | Joined on Jan 2012 @ Belgium
#515
Originally Posted by freemangordon View Post
@DavyP - did you look at cvm code I pushed on gitorious and my build scripts?
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
 

The Following 4 Users Say Thank You to DavyP For This Useful Post:
Posts: 2,770 | Thanked: 10,978 times | Joined on Mar 2010 @ Sofia,Bulgaria
#516
Originally Posted by DavyP View Post
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
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.
 

The Following User Says Thank You to freemangordon For This Useful Post:
Posts: 306 | Thanked: 603 times | Joined on Jan 2012 @ Belgium
#517
Originally Posted by freemangordon View Post
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.
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
 

The Following User Says Thank You to DavyP For This Useful Post:
Posts: 2,770 | Thanked: 10,978 times | Joined on Mar 2010 @ Sofia,Bulgaria
#518
Originally Posted by DavyP View Post
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).
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 .

The pointer passed along to repaintPixmap() is often the same anyhow.
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.

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
Yeah, I was thinking the same, a proposed delay should be pretty enough.
 

The Following 2 Users Say Thank You to freemangordon For This Useful Post:
santiago's Avatar
Posts: 518 | Thanked: 332 times | Joined on Mar 2010 @ italy
#519
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
Attached Files
File Type: zip facebook.zip (133.2 KB, 30 views)
 
Posts: 128 | Thanked: 18 times | Joined on Nov 2011 @ Hungary
#520
Originally Posted by DavyP View Post
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
I tested, but the problem is there. OM starts in landscape mode.
 
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 17:11.