python2.5 - unnecessary multiple processes forked
Hi, I am porting a pygtk application to maemo. It works alright, but I noticed that it was consuming lot of memory, preventing me from opening other applications. When I investigated, I found that my python application was forking 4 more instances of itself, each one identical in memory footprint. Thus they consumed nearly 60-70% of my memory. So I ran my application using pdb and narrowed down to a code segment that was leading to multiple instances of the process. It turned out that when I call run() on hildon.fileChooserDialog object, the dialog opens and at that moment in the top I see 4 more instances being forked. I fail to understand this behavior. I replaced the hildon widgets by pure gtk widgets and I see similar behavior, except that 2 more instances get forked. Also when using gtk.FileChooserDialog, these new instances get created in the instantiation of the dialog object, rather than call to run(). (code included below) So to further explore the problem, I ran same application on my desktop with gtk widgets. But I verified that when fileChooserDialog's run is called, there are no additional instances of python. I am running this code on n770, with 2007 HE and python2.5 runtime. My application code is pure python and not using any additional libraries. In fact following would be a simpler version of it to reproduce the problem: import gtk import hildon #window = gtk.Window(gtk.WINDOW_TOPLEVEL) #fileChooser = gtk.FileChooserDialog( # title=Choose a photo to publish, # buttons=(gtk.STOCK_CANCEL, gtk.RESPONSE_CANCEL, # gtk.STOCK_OK, gtk.RESPONSE_OK)) fileChooser = hildon.FileChooserDialog( window,gtk.FILE_CHOOSER_ACTION_OPEN) result = fileChooser.run() if result == gtk.RESPONSE_OK: print fileChooser.get_filename() Do you have any tips, as to what might be going wrong? This problem is fatal at least on n770 - it will trigger low memory message when other applications are used on the side. Any help will be useful. Thanks, -- --- Jayesh ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: python2.5 - unnecessary multiple processes forked
I tried Lauro's C example in scratchbox environment and see that it's indeed forking 4 more processes. So this is not a python problem. This problem's root cause seems to reside in the widget library. I can't imagine any valid reason for gtk/hildon to fork more processes just to show a GUI dialog. Does anyone know? On 12/31/07, Martin Grimme [EMAIL PROTECTED] wrote: Especially make use of gc.collect() after you have worked with gdk.Pixbuf objects. They won't free their memory otherwise. It's a good habit to free unused Pixbufs with del and run the garbage collector afterwards. And be aware that if a class overrides the __del__ method (some sort of destructor), it won't be freed by the garbage collector at all. Cheers, Martin 2007/12/31, Alex Iliadis [EMAIL PROTECTED]: I recommend using the garbage collector module manually to override the defaults. Python for some reason doesn't reclaim memory fast. So if you put in your code: import gc gc.collect() (at the right spots, probably after the file chooser dialog and after some memory intensive tasks). You should notice a lot of memory being free'd up. -Alex On Sunday 30 December 2007 05:20:34 pm Jayesh Salvi wrote: Hi, I am porting a pygtk application to maemo. It works alright, but I noticed that it was consuming lot of memory, preventing me from opening other applications. When I investigated, I found that my python application was forking 4 more instances of itself, each one identical in memory footprint. Thus they consumed nearly 60-70% of my memory. So I ran my application using pdb and narrowed down to a code segment that was leading to multiple instances of the process. It turned out that when I call run() on hildon.fileChooserDialog object, the dialog opens and at that moment in the top I see 4 more instances being forked. I fail to understand this behavior. I replaced the hildon widgets by pure gtk widgets and I see similar behavior, except that 2 more instances get forked. Also when using gtk.FileChooserDialog, these new instances get created in the instantiation of the dialog object, rather than call to run(). (code included below) So to further explore the problem, I ran same application on my desktop with gtk widgets. But I verified that when fileChooserDialog's run is called, there are no additional instances of python. I am running this code on n770, with 2007 HE and python2.5 runtime. My application code is pure python and not using any additional libraries. In fact following would be a simpler version of it to reproduce the problem: import gtk import hildon #window = gtk.Window(gtk.WINDOW_TOPLEVEL) #fileChooser = gtk.FileChooserDialog( # title=Choose a photo to publish, # buttons=(gtk.STOCK_CANCEL, gtk.RESPONSE_CANCEL, # gtk.STOCK_OK, gtk.RESPONSE_OK)) fileChooser = hildon.FileChooserDialog( window,gtk.FILE_CHOOSER_ACTION_OPEN) result = fileChooser.run() if result == gtk.RESPONSE_OK: print fileChooser.get_filename() Do you have any tips, as to what might be going wrong? This problem is fatal at least on n770 - it will trigger low memory message when other applications are used on the side. Any help will be useful. Thanks, ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- --- Jayesh ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: python2.5 - unnecessary multiple processes forked
I'm not sure but think it is because of gnome-vfs. Don't know proper terminology but maybe each vfs 'provider' in the dialog (like mmc, phone etc.) starts new process or something like that. That sounds correct. I experimented with other dialogs that do no involve filesystem access (NamePasswordDialog, SortDialog), and they do not fork any extra processes. So this behavior seems valid for FileChooserDialog. But then I should be able to cleanup those extra processes when I am done with the FileChooserDialog. I called destroy() on the dialog object, but that doesn't help. -- --- Jayesh ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: python2.5 - unnecessary multiple processes forked
On 12/31/07, Jayesh Salvi [EMAIL PROTECTED] wrote: I'm not sure but think it is because of gnome-vfs. Don't know proper terminology but maybe each vfs 'provider' in the dialog (like mmc, phone etc.) starts new process or something like that. That sounds correct. I experimented with other dialogs that do no involve filesystem access (NamePasswordDialog, SortDialog), and they do not fork any extra processes. So this behavior seems valid for FileChooserDialog. But then I should be able to cleanup those extra processes when I am done with the FileChooserDialog. I called destroy() on the dialog object, but that doesn't help. I guess there isn't much to do - for an app programmer at least. I found the same behavior with osso_pdfviewer. It also uses hildon's FileChooserDialog. But even before that dialog is invoked, multiple processes are forked. ... and they do not disappear until their parent exits. They keep occupying the same amount of memory as their parent. This is really taxing on my n770. If this is the default behavior of gnome-vfs based GTK apps, then I hope it gets improved for embedded devices. -- --- Jayesh -- --- Jayesh ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: python2.5 - unnecessary multiple processes forked
forgot to cc the list. On 12/31/07, Jayesh Salvi [EMAIL PROTECTED] wrote: BTW, are you sure the memory situation is really worse because of this? What I see is, in 'top' all these processes show same percentage of memory utilization under %MEM column (17% or so for each of them). I am not sure if this is virtual memory or physical memory. My application logic flow goes like this: It gets the filename from the user (hence FileChooserDialog) and after some processing it has to open a URL in the browser. It sends an RPC request to the browser. What I am observing is, the browser takes a long time to open that URL and by the time it has opened it, my app gets killed without any error message. Once I had seen a low memory message during this process, but now my parent app gets killed without any such message. I am still trying to establish if the above behavior is only because of memory over consumption. I will update as I make progress. -- --- Jayesh -- --- Jayesh ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: python2.5 - unnecessary multiple processes forked
Thanks for all the info. I am planning to run the FileChooserDialog in a different process than my rest of the app. That may sound weird, but it fits my application's context alright. My pygtk app will run as a service, so that it can be invoked by other applications as well. FileChooserDialog is just one entry point into my app. Detail of my app if you are interested: It is a pygtk GUI that lets you upload images to Flickr or Picasaweb. I have already published the code as Gimp, Inkscape pluginshttp://code.google.com/p/altcanvas/wiki/GimpPublishr. Now I am putting the same code on maemo. I will soon release a .deb file once I iron out some wrinkles. Thanks, Jayesh On 1/2/08, Eero Tamminen [EMAIL PROTECTED] wrote: Hi, ext Jayesh Salvi wrote: I'm not sure but think it is because of gnome-vfs. Don't know proper terminology but maybe each vfs 'provider' in the dialog (like mmc, phone etc.) starts new process or something like that. That sounds correct. I experimented with other dialogs that do no involve filesystem access (NamePasswordDialog, SortDialog), and they do not fork any extra processes. They are not processes, but gnome-vfs worker threads (you don't want the UI to freeze e.g. until network timeouts). So this behavior seems valid for FileChooserDialog. But then I should be able to cleanup those extra processes when I am done with the FileChooserDialog. I called destroy() on the dialog object, but that doesn't help. They remain in the gnome-vfs thread pool even after the UI component is destroyed. The memory usage issue is elsewhere. You could look into your program Private_Dirty memory usage in /proc/PID/smaps file. Or run the same program on your PC under Valgrind Massif plugin: http://maemo.org/development/tools/doc/valgrind http://valgrind.org/docs/manual/ms-manual.html I'm not sure how well that tells about issues in Python code. Is there any memory profiler for Python applications? - Eero -- --- Jayesh ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: python2.5 - unnecessary multiple processes forked
I found out that the sluggishness observed was because of the Microb engine. Last night when I tried by switching to Opera engine, it worked very fast. So it's not the multiple threads that hildon or GTK fork, that cause performance issues. On 1/3/08, Jayesh Salvi [EMAIL PROTECTED] wrote: Thanks for all the info. I am planning to run the FileChooserDialog in a different process than my rest of the app. That may sound weird, but it fits my application's context alright. My pygtk app will run as a service, so that it can be invoked by other applications as well. FileChooserDialog is just one entry point into my app. Detail of my app if you are interested: It is a pygtk GUI that lets you upload images to Flickr or Picasaweb. I have already published the code as Gimp, Inkscape pluginshttp://code.google.com/p/altcanvas/wiki/GimpPublishr. Now I am putting the same code on maemo. I will soon release a .deb file once I iron out some wrinkles. Thanks, Jayesh On 1/2/08, Eero Tamminen [EMAIL PROTECTED] wrote: Hi, ext Jayesh Salvi wrote: I'm not sure but think it is because of gnome-vfs. Don't know proper terminology but maybe each vfs 'provider' in the dialog (like mmc, phone etc.) starts new process or something like that. That sounds correct. I experimented with other dialogs that do no involve filesystem access (NamePasswordDialog, SortDialog), and they do not fork any extra processes. They are not processes, but gnome-vfs worker threads (you don't want the UI to freeze e.g. until network timeouts). So this behavior seems valid for FileChooserDialog. But then I should be able to cleanup those extra processes when I am done with the FileChooserDialog. I called destroy() on the dialog object, but that doesn't help. They remain in the gnome-vfs thread pool even after the UI component is destroyed. The memory usage issue is elsewhere. You could look into your program Private_Dirty memory usage in /proc/PID/smaps file. Or run the same program on your PC under Valgrind Massif plugin: http://maemo.org/development/tools/doc/valgrind http://valgrind.org/docs/manual/ms-manual.html I'm not sure how well that tells about issues in Python code. Is there any memory profiler for Python applications? - Eero -- --- Jayesh -- --- Jayesh ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Development of GUI for N800 Help required
including list. On 1/19/08, Jayesh Salvi [EMAIL PROTECTED] wrote: Best place to start is to use this SDK VM: http://maemovmware.garage.maemo.org/ Best language to do GUI coding on maemo: python http://pymaemo.garage.maemo.org/documentation/pymaemo_tutorial/python_maemo_howto.html If you are looking for an IDE to develop GUI: Gazpacho (or Glade if you prefer) http://maemo.org/development/documentation/how-tos/3-x/gazpacho_hildon_bora.html HTH Jayesh On 1/19/08, nisha jain [EMAIL PROTECTED] wrote: Hi All, I have to develop a GUI for N800 series for project. I am totally new to this field and I want to know how i can install maemo development tool on windows machine? Is it requires some specific programming lang to program? or inbuild components? Please provid me information how shall i start? How i can find tutorials? Regards, Nj ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- --- Jayesh -- --- Jayesh ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: custom dialog
You can find several examples of deriving from gtk.Dialog with this query: http://www.google.com/codesearch?hl=enlr=q=lang%3Apython+gtk.DialogbtnG=Search Jayesh On 2/5/08, Michele Tameni [EMAIL PROTECTED] wrote: Ho, i'm approcing the development on my new cool nokia device, but i can't find info on how to make a very simple thing. I've a treeview and i need to edit the entry in one row. i don't want to open another window only for some info to edit or enter, so i'm looking for how opening a custom dialog box ( like many apps actually do) for get the info i need to retrieve. I'm using python, but if you know how to do this in other language is fine anyway. thanks a lot -- michele tameni http://www.amdplanet.it ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- --- Jayesh ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
[announcement] Inkface 0.1
Hi all, I have been working on SVG based GUI design for past few months. At Maemo summit I showed the demo of my SVG based GUI apps to some of you. I was delighted by the positive response. I am glad to announce version 0.1 of the SVG based GUI framework Inkface. With this framework, you can design beautiful GUIs in an Image editor like Inkscape and glue it with your application logic in python. Moreover changing the GUIs is just a matter of replacing the input SVG file. Check out this demo video http://blip.tv/file/1355876. If you want to try these applications yourself: - Install the .deb packages (libaltsvghttp://altcanvas.googlecode.com/files/libaltsvg_0.1.0_armel.deb, inkface-pythonhttp://altcanvas.googlecode.com/files/inkface-python_0.1.0_armel.deb) (for diablo) - Download and execute the python scripts: Keyboard (.pyhttp://altcanvas.googlecode.com/svn-history/r635/trunk/inkface/tests/inkface-keyboard.py .svghttp://altcanvas.googlecode.com/svn-history/r635/trunk/inkface/tests/data/keyboard-entry.svg) IRC (.pyhttp://altcanvas.googlecode.com/svn-history/r635/trunk/inkface/tests/inkface-irc.py .svghttp://altcanvas.googlecode.com/svn-history/r635/trunk/inkface/tests/data/irc.svg ) # Install Inkface libraries dpkg -i libaltsvg_0.1.0_armel.deb inkface-python_0.1.0_armel.deb # Keyboard demo python inkface-keyboard.py keyboard-entry.svg # IRC demo python inkface-irc.py irc.svg Check out Project wiki: Inkface http://code.google.com/p/altcanvas/wiki/InkFace More background on project is available herehttp://jyro.blogspot.com/2008/09/inkface-svg-based-gui-design.html . All ears for the feedback! Thanks! -- --- Jayesh ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
fremantle opengl errors
Hi, I am trying to run a simple opengl program inside the recently released fremantle SDK. I was delighted to see that it built successfully, but it threw bunch of low level errors during runtime. [sbox-FREMANTLE_X86: ~/gl-cairo-simple] DISPLAY=:2 ./gl-cairo-simple FreeFontPath: FPE /usr/share/fonts/X11/misc refcount is 2, should be 1; fixing. Extended Input Devices not yet supported. Impelement it at line 625 in ../../../../hw/kdrive/src/kinput.c Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list! Couldn't open SDL-window: X11 driver not configured with OpenGL FreeFontPath: FPE /usr/share/fonts/X11/misc refcount is 2, should be 1; fixing. Extended Input Devices not yet supported. Impelement it at line 625 in ../../../../hw/kdrive/src/kinput.c Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list! The example program was downloaded from cairo opengl docs[1], it needs cairo, GL and SDL libraries - all are present in the SDK. I ran Xephyr as X server at DISPLAY :2, and was assuming that the opengl output will be rendered in that window. Questions: 1. Is there any way I can work around above errors OR do they need fix in the kdrive implementation? 2. With my limited knowledge of X servers and opengl: I don't understand if kdrive is a replacement for Xephyr OR both will be satisfying different needs? 3. I am running my SDK inside an ubuntu VM - so h/w acceleration won't work. But will the acceleration happen automatically in software, or will I have to do any special settings? Please let me know if someone can answer above queries. [1] http://people.freedesktop.org/%7Emacslow/gl-cairo-simple.tar.bz2 Thanks. --- Jayesh blog http://jyro.blogspot.com |twit http://www.twitter.com/jyro |code http://code.google.com/p/altcanvas/ | ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: fremantle opengl errors
On Mon, Dec 15, 2008 at 12:09 AM, Eero Tamminen eero.tammi...@nokia.comwrote: Hi, ext Jayesh Salvi wrote: Couldn't open SDL-window: X11 driver not configured with OpenGL I think this is your problem. Does SDL work when not using OpenGL (I haven't tried the SDK myself yet)? If yes, you could file a bug about enabling OpenGL for SDL for Fremantle. Sure I will check that. AFAIK kdrive is a (minimal) X configuration (and Xephyr is an X server that works on top of X display instead of a real HW). Ok. I compiled and ran glxgears and it worked perfectly inside Xephyr. AFAIK x86 SDK uses Mesa to do OpenGL in software (I think this is full GL, not the EGL spec subset like on the target). Will the next release of fremantle SDK contain OpenGL ES libraries? I have so far found only PowerVR that has OpenGL ES SDK (and android, but that's only java). Are there any other OpenGL ES libraries (FOSS of course) that we can develop with for now? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Frets on Fire on Fremantle
Hi all, I have ported the popular desktop game Frets on Fire (Guitar Hero clone) to Fremantle. It leverages the OpenGL support in the new platform. Here is the video (http://blip.tv/file/1839929) You can find the details of the port on my blog post ( http://jyro.blogspot.com/2009/03/frets-on-fire-on-maemo-5-fremantle.html). Some tweaks in the GUI and we might convert the next Nokia tablet into an electric guitar. Feedback is welcome! -- Jayesh code http://code.google.com/p/altcanvas/ | twithttp://www.twitter.com/jyro| blog http://jyro.blogspot.com/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frets on Fire on Fremantle
On Thu, Mar 5, 2009 at 4:00 PM, sami.kyost...@nokia.com wrote: Hi, I have ported the popular desktop game Frets on Fire (Guitar Hero clone) to Fremantle. It leverages the OpenGL support in the new platform. Here is the video (http://blip.tv/file/1839929) You can find the details of the port on my blog post ( http://jyro.blogspot.com/2009/03/frets-on-fire-on-maemo-5-fremantle.html). Some tweaks in the GUI and we might convert the next Nokia tablet into an electric guitar. Great work! I was thinking of doing the port myself, but you seem to have beaten me to it :) I'm afraid there's still some work to be done, however. Frets on Fire uses OpenGL graphics, while in Maemo 5 we only have OpenGL ES 1.1/2.0. The graphics code in the game will therefore have to be mostly rewritten to use the more limited set of features available in OpenGL ES. The graphics complexity will probably also need to be tuned down to get decent performance. I'm not sure why the Fremantle SDK ships with the desktop OpenGL libraries in the first place, though. Oh. That's confusing. So Maemo SDK ships with OpenGL and not OpenGL ES? I had my doubts when I compiled PyOpenGL. It compiled without any problems. I didn't find anywhere if PyOpenGL works with OpenGL ES or not. (probably not). So I was little surprised that it compiled. If that's the case, then the assumption that anything that works in SDK will work on final device as well, is not true. Is that so? -- Jayesh - Sami ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
question on python opengl ES bindings
Hi, I was investigating OpenGL python bindings on Fremantle. As I understand from previous discussion on this topic: although PyOpenGL will work in Fremantle SDK, it won't work on real hardware which will run OpenGL ES. So I started looking for python bindings for OpenGL ES. From the top search results, I found out the pys60 project by Nokia has bindings for OpenGL ES ( http://www.khronos.org/message_boards/viewtopic.php?f=4t=855). (I am surprised to see how old that post is.) I checked the pys60 source code 1.4.5 and it indeed has opengles bindings. My question is, is there a plan to have similar OpenGL ES python bindings on Fremantle? Or is it just clutter and pyclutter? Thanks, Jayesh ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
