maemo.org - Talk
Page 48 of 85 « First 384647 48 495058 Last »
Show 40 post(s) from this thread on one page

maemo.org - Talk (https://talk.maemo.org/index.php)
-   Applications (https://talk.maemo.org/forumdisplay.php?f=41)
-   -   [BETA RELEASE] PhoneME Advanced (Java Mobile) (https://talk.maemo.org/showthread.php?t=81969)

freemangordon 2012-03-28 18:22
Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 
Quote:
Originally Posted by DavyP (Post 1185142)
Nice to hear you have a working base MIDP stack. The errors you get with JSR 75 seem to be related to the abstractions for running midlets on a CDC stack rather than a CLDC stack.

I would suggest to leave out JSR 75 support for the time being. I will try to address this issue when I add instructions for including JSR 179 (Location API) support. I still need to clean up this part.

Davy
Well, the reason why I am trying to have libsvm.so build with the same functionality as what is distributed by you in .deb, is because I want to try to speedup/optimize the whole thing a bit. An example - in your early builds cvm memory allocation with Opera was about 12% (as shown in top) while in later it is 20% and more. Also Opera scrolling was silk smooth in those earlier builds, while there is a lot of stutter in later. Your builds does not use arm7l and SGX features, which I am familiar with. What I saw in cvm Qt sources is a memory inefficiency I am sure I can get rid of (framebuffer is memcpy'ed to a new buffer, which is then used for QImage, which is then used for QPixmap, and that QPixmap is rotated 270 deg when in portrait). And so on, and so on. But I need a working build tree, to be able to play with different options so at the end of a day a simple benchmark could prove is it faster or slower.

Re location API - I don't think using Qt mobility is the best solution for n900, Qt is a memory hungry animal. There are better solutions AFAIK:
http://wiki.maemo.org/Documentation/...ng_liblocation

I think I can help a lot on that side, we can just agree on the interface you need, and I will implement it in a .so file, so you won't need scratchbox or anything to use native Maemo5 GPS support.

The same is with multimedia support, but lets leave that for now.

I would really appreciate if you could give me some hints on how to workaround missing parts that prevent me from having the fully functional libsvm.so build (to the point your build is functional, of course)

freemangordon 2012-03-28 18:24
Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 
Quote:
Originally Posted by DavyP (Post 1185205)
Yeah, thanks for testing :-). Having a N900 has been quite helpful for me for testing purposes as well.

I actually had some fun disassembling the device. I bought a new digitizer to replace the scratched screen at Tmart.com for 8 EUR, but unfortunately it is missing the metal frame at the back with the 6 screw holes and I cannot seem to separate the metal frame from the original one. Should anyone have some tips where to buy this instead, they are most welcome :-).
Hmm, better PM vi_, I think he can help.

Quote:
Regarding your problem: I presume you are talking about 3G connections? This is not trivial because there are different ways of network connectivity (WiFi, 3G, USB). On Windows Mobile, there is something called ConnectionManager to take care of this. I have no idea if Maemo has APIs to do just that.

Davy
Yes, it is called ICD:
http://wiki.maemo.org/Documentation/...o_Connectivity

birefringence 2012-03-28 19:26
Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 
Quote:
Originally Posted by DavyP (Post 1184857)
See what happens if you add "-Duser.timezone=GMT+2:00" to the
cvm command line parameters.

In Android, the front-end application (running in Dalvik VM) takes
the current timezone offset (in msec) constructs the above
GMT based timezone, and passes that along when calling cvm.
This means I have to do something similar in Qt4.

Davy
Yep, that fixes it :-)

DavyP 2012-03-28 21:15
Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 
Quote:
Originally Posted by freemangordon (Post 1185207)
Well, the reason why I am trying to have libsvm.so build with the same functionality as what is distributed by you in .deb, is because I want to try to speedup/optimize the whole thing a bit. An example - in your early builds cvm memory allocation with Opera was about 12% (as shown in top) while in later it is 20% and more. Also Opera scrolling was silk smooth in those earlier builds, while there is a lot of stutter in later. Your builds does not use arm7l and SGX features, which I am familiar with. What I saw in cvm Qt sources is a memory inefficiency I am sure I can get rid of (framebuffer is memcpy'ed to a new buffer, which is then used for QImage, which is then used for QPixmap, and that QPixmap is rotated 270 deg when in portrait). And so on, and so on. But I need a working build tree, to be able to play with different options so at the end of a day a simple benchmark could prove is it faster or slower.

Re location API - I don't think using Qt mobility is the best solution for n900, Qt is a memory hungry animal. There are better solutions AFAIK:
http://wiki.maemo.org/Documentation/...ng_liblocation

I think I can help a lot on that side, we can just agree on the interface you need, and I will implement it in a .so file, so you won't need scratchbox or anything to use native Maemo5 GPS support.

The same is with multimedia support, but lets leave that for now.

I would really appreciate if you could give me some hints on how to workaround missing parts that prevent me from having the fully functional libsvm.so build (to the point your build is functional, of course)
Obviously, your expertise to improve this build would be much appreciated. Give me some to sort things out. I am doing my best with the limited spare time I have.

I actually used liblocation before to support GPS functionality, but
since this library was not available on MeeGo, but Qt Mobility was on Maemo, I chose that one for both.

Davy

DavyP 2012-03-28 21:45
Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 
Quote:
Originally Posted by DavyP (Post 1185312)
Obviously, your expertise to improve this build would be much appreciated. Give me some to sort things out. I am doing my best with the limited spare time I have.

I actually used liblocation before to support GPS functionality, but
since this library was not available on MeeGo, but Qt Mobility was on Maemo, I chose that one for both.

Davy
I added a couple of more patches (and one that contains all
modifications) to fix the build issues with JSR75 as well as addon
packages for JSR179 and JSR135.

The build you can produce with these updates should be the
same as my own builds.

Davy

DavyP 2012-03-28 22:06
Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 
Quote:
Originally Posted by freemangordon (Post 1185207)
What I saw in cvm Qt sources is a memory inefficiency I am sure I can get rid of (framebuffer is memcpy'ed to a new buffer, which is then used for QImage, which is then used for QPixmap, and that QPixmap is rotated 270 deg when in portrait). And so on, and so on. But I need a working build tree, to be able to play with different options so at the end of a day a simple benchmark could prove is it faster or slower.
Note that while this is true, there is no copying of the framebuffer going on for QImage and QPixmap. I need the QPixmap structure to render text using the Qt text drawing routing rather than the built-in monospace fixed bitmap font of phoneme. There might be some overhead, but I am not sure how much. You can always try the JBenchmark and JBenchmark2 midlets which I used for comparison.

The rotation will cause some overhead I am sure. It is the quickest fix for the N9 as I have not been able to properly support rotation (as I would have to use QML for that).

Davy

[DarkGUNMAN] 2012-03-29 06:36
Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 
If you change your Internet Connection settings to Always ask, and try to open a MicroB browser window you will get prompted which connection or APN to use (WiFi, 3G etc)- getting the same functionality available in PhoneME would be great!

I have started putting Opera Mini through its paces by opening multiple tabs.. this isn't something I do all the time since the back/forward buttons are lightening fast compared to other browsers.
After 4 tabs are open processor load hits maximum and display goes jerky, closing them makes no difference so i just close the browser and open another copy and resume from where I left off in the History.

Like I said I don't use tabbed browsing often, but I thought I'd let you know where performance is getting hit.

I do find I am using Opera Mini more than MicroB since I am now without a car and use 2G for bus journeys due to patchy 3G cover, so thank you again for your efforts in bringing PhoneMe to this platform.. also if Freemangordon and other members of the community are willing to help then things are looking good :)

DavyP 2012-03-29 08:47
Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 
Quote:
Originally Posted by [DarkGUNMAN] (Post 1185469)
If you change your Internet Connection settings to Always ask, and try to open a MicroB browser window you will get prompted which connection or APN to use (WiFi, 3G etc)- getting the same functionality available in PhoneME would be great!

I have started putting Opera Mini through its paces by opening multiple tabs.. this isn't something I do all the time since the back/forward buttons are lightening fast compared to other browsers.
After 4 tabs are open processor load hits maximum and display goes jerky, closing them makes no difference so i just close the browser and open another copy and resume from where I left off in the History.

Like I said I don't use tabbed browsing often, but I thought I'd let you know where performance is getting hit.

I do find I am using Opera Mini more than MicroB since I am now without a car and use 2G for bus journeys due to patchy 3G cover, so thank you again for your efforts in bringing PhoneMe to this platform.. also if Freemangordon and other members of the community are willing to help then things are looking good :)
This could be a memory related problem. By default I start midlets
with a max Java heapspace of 12MB. Maybe Opera is using a lot
to store and cache all its content, and increasing this limit a bit
would help to open up more tabs.

Cheers,
Davy

freemangordon 2012-03-29 17:38
Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 
@DavyP - thanks for the last patches, now opera runs. In short - everything is fine :)

I've played a little bit with cvm code and the result so far:

JBenchmark2, no overclock, charger connected, using max score from several runs:

landscape:
DavyP cvm - 862
freemangordon cvm - 874

portrait:
DavyP cvm - 760
freemangordon cvm - 774

not and impressive speedup (only about 2%) :D , but yet

Next thing I will do is to try to get rid of that memcpy(by passing cvm allocated buffer as screen buffer to libcvm), it should give us additional performance boost.

Again, thanks a lot for making this port to maemo and sharing your experience with us.

EDIT:
any chance to PM me a link to download JBenchmark, google finds a site when a registration is needed, but I don't want my inbox full with spam.

Estel 2012-03-29 19:34
Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 
After first batch of optimization, maybe it will be time for extras-devel?


All times are GMT. The time now is 15:23.
Page 48 of 85 « First 384647 48 495058 Last »
Show 40 post(s) from this thread on one page

vBulletin® Version 3.8.8