What Will Be The Ui?

[efegea]

The OpenGL ES integration will be released as part of 4.5.0 which I believe is currently slated for Autumn.

But the Pandora will be released before Autumm..

 

[Julius]

So? just use the regular qtopia toolset until then and have an upgrade with the 3d accel. effects afterward (or use Beta software until then).

Personally I would love to see this toolkit on the pandora as there are lots and lots of great PDA programs written for the qtopia version of the Zaurus operating system.

Edit: See here:
http://www.killefiz.de/zaurus/

 

[Squidge]

The launcher I'm thinking about would be a command line program where you pass it the path to the game you want to execute.

Ok, how you were talking I assumed you were creating a graphical launcher, not a command line program.

Oh well, back to the drawing board...

 

[icurafu]

I have a question on memory usage.

I wanna be able to use the entire 128MB of RAM. How much ram will Qtopia consume and is there is option to dump the entire OS memory on fullscreen apps and then reload when the application is exited?

What would need to be done to dump the ram, do we need to detach from hardware. Can anyone estimate how long this would take? or how many seconds would be added to the execution of each of these high memory consuming applications?

 

[Orkie]

No, let me find the post.

Well?

 

[atomicthumbs]

No, let me find the post.

Well?


wait, school intrudes

Edit:

I was mistaken. Apparently my memory got confused and "interface like the EEE" became "EEE's interface" by mixing with a few other posts from the massive topic, which associated in my mind to "KDE" because the EEE's interface is based on KDE, which uses QT.

Whoops. My mind works in strange ways.

 

[TomCooksey]

The launcher I'm thinking about would be a command line program where you pass it the path to the game you want to execute.

Ok, how you were talking I assumed you were creating a graphical launcher, not a command line program.



I was thinking of a command-line launcher which was launched by a graphical one - but now you mention it, you might as well stick the logic in the graphical launcher. Qtopia ships with a launcher, but I think it's designed with phones/PDAs in mind. I'm sure we can do something much nicer with the much higher resolution LCD on the Pandora.

QUOTE

I wanna be able to use the entire 128MB of RAM. How much ram will Qtopia consume and is there is option to dump the entire OS memory on fullscreen apps and then reload when the application is exited?



What your basically talking about is swap. The inactive process's memory is flushed to disk to allow an active process to use as much RAM as possible.

The problem is where you want to dump it to. The only place you have on the pandora is flash memory and using flash as swap space wares it out. What I think you could do instead (and I think Qtopia supports this) is terminate all the GUI applications asking them to save their state. When the game ends, the GUI applications are re-launched and told to restore their state. The the applications still need to save their state somewhere, which again will eventually ware out the flash.

Qtopia's memory usage varies depending on what applications you have running. But, as an indication, the padnavigator example uses 27MB on my x86 debug build. Now that seems a lot, but you have to remember that includes all the qt libraries loaded into memory and the complete windowing system running too. Qt/Embedded uses an in-process window system, so the first application to be launched acts as the "server". If you compare memory usage to X, you have to add the amount of memory the X server and the window manager is using.

 

[Orkie]

Qtopia's memory usage varies depending on what applications you have running. But, as an indication, the padnavigator example uses 27MB on my x86 debug build. Now that seems a lot, but you have to remember that includes all the qt libraries loaded into memory and the complete windowing system running too. Qt/Embedded uses an in-process window system, so the first application to be launched acts as the "server". If you compare memory usage to X, you have to add the amount of memory the X server and the window manager is using.

Yes, it does seem like a lot considering the fact that the GP2X X server uses 5-6MB RAM and something like IceWM would never use more than 2MB extra. Using a lot of RAM doesn't concern me - it is meant to be used after all, but what are load times going to be like for huge a huge application? Does it stand any chance whatsoever of beating a lightweight X setup?

 

[ldesnogu]

Yes, it does seem like a lot considering the fact that the GP2X X server uses 5-6MB RAM and something like IceWM would never use more than 2MB extra. Using a lot of RAM doesn't concern me - it is meant to be used after all, but what are load times going to be like for huge a huge application? Does it stand any chance whatsoever of beating a lightweight X setup?

Hum Qt is C++, that says a lot about memory footprint

 

[TomCooksey]

Yes, it does seem like a lot considering the fact that the GP2X X server uses 5-6MB RAM and something like IceWM would never use more than 2MB extra.

So that's 8 MB of ram used by X server and window manager. Then you have the client application, plus the libraries it links against like gtk+, cairo, pango, xlib, etc. Compile all that with debug symbols and I'm sure it would come to more than 27MB.

Using a lot of RAM doesn't concern me - it is meant to be used after all, but what are load times going to be like for huge a huge application? Does it stand any chance whatsoever of beating a lightweight X setup?

Well most of the memory is taken up by the libraries. As they are shared libraries they don't need to be loaded again. Doing a pmap -d on that pad navigator, I see that the actual executable code is only using 108 KB (I've trimmed out everything < 100K from the output):

QUOTE

0000000008048000 108 r-x-- 0000000000000000 008:00003 padnavigator
0000000008065000 3760 rw--- 0000000008065000 000:00000 [ anon ]
00000000f6961000 1132 rw--- 00000000f6961000 000:00000 [ anon ]
00000000f6a7c000 328 r-x-- 0000000000000000 008:00003 libtiff.so.3.8.2
00000000f6af6000 236 r-x-- 0000000000000000 008:00003 libQtXml.so.4.4.1
00000000f6b33000 364 r-x-- 0000000000000000 008:00003 libmng.so.1.0.0
00000000f6c30000 456 r---- 0000000000000000 008:00003 DejaVuSans-Bold.ttf
00000000f6ca2000 484 r---- 0000000000000000 008:00003 DejaVuSans.ttf
00000000f6d1b000 328 rw--- 00000000f6d1b000 000:00000 [ anon ]
00000000f6d77000 280 r-x-- 0000000000000000 008:00003 libQtSvg.so.4.4.1
00000000f6dbf000 120 r-x-- 0000000000000000 008:00003 libjpeg.so.62.0.0
00000000f6e10000 1204 rw-s- 0000000000000000 000:00008 [ shmid=0x8398004 ]
00000000f6f3d000 252 r---- 0000000000000000 008:00003 LC_CTYPE
00000000f6f7c000 896 r---- 0000000000000000 008:00003 LC_COLLATE
00000000f705e000 1192 r-x-- 0000000000000000 008:00003 libc-2.6.1.so
00000000f719a000 144 r-x-- 0000000000000000 008:00003 libm-2.6.1.so
00000000f71c1000 880 r-x-- 0000000000000000 008:00003 libstdc++.so.6.0.8
00000000f72df000 2444 r-x-- 0000000000000000 008:00003 libQtCore.so.4.4.1
00000000f754c000 840 r-x-- 0000000000000000 008:00003 libQtNetwork.so.4.4.1
00000000f7623000 136 r-x-- 0000000000000000 008:00003 libpng12.so.0.22.0
00000000f766c000 9212 r-x-- 0000000000000000 008:00003 libQtGui.so.4.4.1
00000000f7f6b000 132 r---- 00000000008fe000 008:00003 libQtGui.so.4.4.1
00000000f7f96000 104 r-x-- 0000000000000000 008:00003 ld-2.6.1.so
mapped: 25940K writeable/private: 5516K shared: 1268K



So it basically breaks down to:
Application: 108 K
Qt Libraries (Core, Gui, Network, Xml) : 12,732 KB
Non-Qt libraries: 3,132 KB
Other stuff*: 9,968 KB

* Other stuff are things like the stack, heap, shared memory, framebuffer (This is using a 640x480x32-bit framebuffer, which is another 1200 KB added to the footprint), etc.

I hope that clears things up a bit!

 

[ldesnogu]

So that's 8 MB of ram used by X server and window manager. Then you have the client application, plus the libraries it links against like gtk+, cairo, pango, xlib, etc. Compile all that with debug symbols and I'm sure it would come to more than 27MB.

Debug symbols are not loaded (unless you debug of course ), so are they really relevant to the discussion?

 

[TomCooksey]

Debug symbols are not loaded (unless you debug of course ), so are they really relevant to the discussion?

Good point!

 

[Chip]

What your basically talking about is swap. The inactive process's memory is flushed to disk to allow an active process to use as much RAM as possible.

The problem is where you want to dump it to. The only place you have on the pandora is flash memory and using flash as swap space wares it out.

Any reason you couldn't dump it to an SD card? I'm not really familiar with how Linux handles swap space. Does it need an actual partition, or could you use a swap file? Is it beyond the realm of possibility to allow users to create a file called "pandora.swap" or something on one or all of their SD cards, have the system check for the presence of that file, and use it if it's there? The file would have to be at least 128MB to contain a complete RAM image, but you could make it as big as you want for programs that might need more virtual memory. Considering most people will be using 2-8GB SD cards, 128MB is a small amount of overhead.

I always assumed we will be able to use space on SD cards for virtual memory. You only have 256MB of flash built in to the Pandora, and once you get an OS and libraries and a couple frequently used apps, you might not have 128MB left for a full RAM image.

 

[Parkydr]

So that's 8 MB of ram used by X server and window manager. Then you have the client application, plus the libraries it links against like gtk+, cairo, pango, xlib, etc. Compile all that with debug symbols and I'm sure it would come to more than 27MB.

I'm running the X server with a GTK based client application on the GP2X (but statically linked), so it can't be using much more than 27MB or the GP2X would run out of memory.

I'll check the actual figures.

 

[TomCooksey]

I'm running the X server with a GTK based client application on the GP2X (but statically linked), so it can't be using much more than 27MB or the GP2X would run out of memory.

I'll check the actual figures.

Yeah, I'd love to see the comparison break-down! Does the GTK+ based application use Pango & Cairo?

 

[Orkie]

Is it beyond the realm of possibility to allow users to create a file called "pandora.swap" or something on one or all of their SD cards, have the system check for the presence of that file, and use it if it's there?

Not at all. In fact, GPE on the GP2X recommends the usage of such a swap file. Many people here would moan about it shortening the life of your SD, but I personally don't think it makes enough of a difference that you wouldn't want to replace your SD anyway purely due to space reasons by the time it died. However, it won't really be of much use in reality because swap is generally very slow (all it'll do is stop the machine running out of memory entirely and start playing up).

So that's 8 MB of ram used by X server and window manager. Then you have the client application, plus the libraries it links against like gtk+, cairo, pango, xlib, etc. Compile all that with debug symbols and I'm sure it would come to more than 27MB.

I've actually changed my mind now . My 8MB value was based on an old statically linked X server. Dynamically linked, it is only 3MB, including the required X libs loaded, which would give about 5MB usage for a basic setup. Of course, many GUI toolkits (like Qt and GTK+, which are massively overblown for most uses) take up lots of RAM, but I'm sure there are others that the authors Pandora-specific applications may be able to use also. I do realise Qt is not just GUI functions however (though neither is GTK+).

Both FOX and FLTK look quite decent to me and are under the LGPL (the GPL licensing of Qt is a real problem in my opinion).

 

[Parkydr]

Yeah, I'd love to see the comparison break-down! Does the GTK+ based application use Pango & Cairo?

It's FBReader and uses both Pango and Cairo.

 

[Svartalf]

Not at all. In fact, GPE on the GP2X recommends the usage of such a swap file. Many people here would moan about it shortening the life of your SD, but I personally don't think it makes enough of a difference that you wouldn't want to replace your SD anyway purely due to space reasons by the time it died. However, it won't really be of much use in reality because swap is generally very slow (all it'll do is stop the machine running out of memory entirely and start playing up).

Someone did the math a while back on the modern flash devices. Yes, you don't want to continually write to the thing. No, it's not as bad as people thinks it is- unless you're using crap parts, and then you're on your own. A SSD, SD, or CF under heavy usage will last at least 3-5 years before failing under continuous writing, esp. if you don't constrain the filesystem to a small part of the flash device.

Flash has changed- while it's better to avoid swap spaces, if the resources don't allow not having them, it's not a terribly bad thing to do that sort of thing. Seems to work decently enough on my N800.

 

[TomCooksey]

Yeah, I'd love to see the comparison break-down! Does the GTK+ based application use Pango & Cairo?

It's FBReader and uses both Pango and Cairo.


Perfect! Please post the output of pmap -d on it, I'm dying to see the difference!

 

[Parkydr]

I haven't got pmap on the GP2X, I'll try it on qemu when I've reinstalled it

I was using the Debian testing distro, but now it says kernel to old on the GP2X. I'll drop back to stable.