Active Topics
-
The N900 is now 15 years old! (7)
to Nokia N900 by Danct12 - 1 day, 1 hr ago -
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (4)
to SailfishOS by Maemish - 1 day, 20 hrs ago -
F(x)tec Pro1x (QWERTY) for sale (0)
to Buy & Sell by aln00000 - 4 days, 5 hrs ago - more...
|
2012-04-10
, 12:23
|
|
Posts: 306 |
Thanked: 603 times |
Joined on Jan 2012
@ Belgium
|
#512
|
Originally Posted by octave
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.
Whenever i chose http as proxy server on opera mini 6.5 it doesn't work.why
Davy
|
|
2012-04-10
, 12:24
|
|
Posts: 306 |
Thanked: 603 times |
Joined on Jan 2012
@ Belgium
|
#513
|
Originally Posted by demludi
Nice to hear that it works (although I am not a Nimbuzz user myself).
Nimbuzz working on N900 !!!
http://talk.maemo.org/showthread.php...hlight=nimbuzz
Davy
| The Following User Says Thank You to DavyP For This Useful Post: | ||
|
|
2012-04-10
, 13:34
|
|
Posts: 306 |
Thanked: 603 times |
Joined on Jan 2012
@ Belgium
|
#515
|
Originally Posted by freemangordon
Yes, but I have not come around to integrate your changes into my build.
@DavyP - did you look at cvm code I pushed on gitorious and my build scripts?
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: | ||
|
|
2012-04-10
, 16:03
|
|
Posts: 3,074 |
Thanked: 12,960 times |
Joined on Mar 2010
@ Sofia,Bulgaria
|
#516
|
Originally Posted by DavyP
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
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
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: | ||
|
|
2012-04-10
, 16:25
|
|
Posts: 306 |
Thanked: 603 times |
Joined on Jan 2012
@ Belgium
|
#517
|
Originally Posted by freemangordon
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.
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
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: | ||
|
|
2012-04-10
, 17:30
|
|
Posts: 3,074 |
Thanked: 12,960 times |
Joined on Mar 2010
@ Sofia,Bulgaria
|
#518
|
Originally Posted by DavyP
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
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
 |
|
2012-04-12
, 03:50
|
|
Posts: 518 |
Thanked: 334 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
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
|
|
2012-04-14
, 11:47
|
|
Posts: 136 |
Thanked: 19 times |
Joined on Nov 2011
@ Hungary
|
#520
|
Originally Posted by DavyP
I tested, but the problem is there. OM starts in landscape mode.
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
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