<div dir="ltr">On Tue, Sep 30, 2008 at 6:55 PM, Alex Osborne <span dir="ltr"><<a href="mailto:ato@meshy.org">ato@meshy.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
You mean start Mofi, then switch to a different app and back to the<br>
still running Mofi? The window renders virtually instantly for me,<br>
there's a little flash of it redrawing but you really have to watch<br>
for it and it's not noticeably worse than any other app. I'm<br>
switching between xterm and Mofi on Debian on the FreeRunner. The<br>
fact I can't see it could be due to Debian using a different GTK<br>
theme, I notice the font (and hence all the widets) are much smaller<br>
on Debian than on OM 2007/8, so it might render faster.<br>
</blockquote><div><br>It might be because I use a Qtopia-based installation (2008.8-update) then, and GTK might run better on Debian 'natively', I guess. <br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
The fact that Python is used for the application logic should have<br>
zero effect on the redraw speed. This is because the code that does<br>
the drawing (GTK), is actually written in C. The Python code tells<br>
GTK once when the window is created, "hey I want five buttons and a<br>
textbox with this text, in this arrangement, you figure out the<br>
rest", it's then GTK's responsibility to redraw them and tell python<br>
when a button gets clicked or a menu item is selected. In a normal<br>
application that's just using standard widgets and not doing any<br>
custom drawing, redraws (like switching between applications)<br>
shouldn't execute any Python code at all.<br>
</blockquote><div><br>This is very informative, thanks. I still have the feeling that GUI performance is poor when the executable is written in python. Maybe its just me.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
But for typical GUI programs processor speed is usually largely<br>
irrelevant as long as the underlying toolkit is not completely<br>
broken. If a GUI is not responding it's a problem with how the<br>
program is structured, it should be doing something asynchronously<br>
instead of blocking the event loop.<br>
<br>
</blockquote></div>I just hope everybody follows best practices. At the end of the day, all I need is something that is responsive.<br></div>