<div class="gmail_quote">2009/2/7 Tiago Marques <span dir="ltr"><<a href="mailto:tiagomnm@gmail.com">tiagomnm@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">That seems a good idea.</div><div>The use of SVGs seems unnecessary. Although an awsome functionality, which probably saves a lot of work, would allow to scale the use of Sugar to systems with bigger screens - were it probably will never be in use. I've never seen SVGs being used extensively in a desktop system, let alone an "embedded" one. </div>
</blockquote><div><br></div><div>Caching the SVGs as pixmaps can help this out a lot.  I remember IRIX from the mid 90s using vector-based icons, and it didn't seem to have performance issues.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div></div><div class="Ih2E3d">
<div>As I talked with some people that know more Python than me, they argued that programmer productivity would be a major factor for it's use in some situations. I haven't heard that argument here. I haven't read a good argument that justifies the burden of using an interpreted language in a desktop environment, so it really does seem stubbornness more than anything else, even more and it's all already written in Python.</div>
</div></blockquote><div><br></div><div>It is wonderful to be able to modify a part of the Sugar shell or an Activity directly on the XO, without the need for a compiler and a wide variety of installed headers and libraries eating up space on your disk, not to mention obscure build systems and megabytes of build artifacts.  </div>
<div><br></div><div>It's also great that most activities are <100k downloads and are totally cross platform and architecture independent.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d"><div></div></div>
<p>No matter what interpreted language you're using, it will always stink. Either it's java, python, javascript, whatever. Sugar isn't a webapp, it doesn't even need to be so portable that it can't be written in a language that can be compiled.</p>
</blockquote><div>Here's the difference:  In Sugar, Python fills the role of the *glue* code.  It doesn't do any real work itself.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<p></p>
<p>Even in powerful machines, most programs I have used written in Java have a huge amount of computing and memory overhead - and Java isn't the worst of it, I read.</p></blockquote><div>Do you need high performance for every program?  I use GMail all day and have never had a performance issue with it. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><p></p><p>I can't stress this enough: unless the whole OLPC project is starting to take aim at building a laptop that doesn't cost less than $170, I don't see any reason at all not to properly optimize the software. You will always be running some kind of over powered, embedded type system, with little RAM and CPU power.</p>
</blockquote><div>I completely agree, I just want to make sure the optimization happens to the right parts - the parts that do the heavy lifting.  And the algorithms that control the parts that do the heavy lifting.</div>
<div><br></div><div>For example, I was recently involved in a discussion about the pulsing icon that is shown when activities launch.  It turns out, the *entire screen* was being redrawn at 10fps, not just the activity icon.  Not to mention that the icon caching was not working, so the .svg file was being reparsed each frame and going through a text filter like s/&stroke_color;/#aabbcc/ to achieve the pulsed color.  Fortunately Benjamin Berg corrected this today.</div>
<div><br></div><div>Another one, I have had to rewrite large chunks of THREE of my activities to overcome performance issues in Cairo (which is an optimized library written in C).  I have written several games and other realtime activities for the XO and not yet seen Python become a bottleneck.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><p>The whole project is taking the show source thing way too far, hurting you too much, especially as that is still far from "the vision". You already have Pippy, which should be enough for most kids. The really good kids won't have a problem doing the work to go to the next step(building activities and such) and you can always leave the door open for python activities, while having the basis of Sugar in C, C++ or something. Isn't that what bindings between languages are for?</p>
</blockquote><div>I'm telling you, I'm still looking for some solid performance numbers.  Memory issues I am more inclined to believe but again, actually optimizing the problem (controlling Python's garbage collector) is a much better solution than throwing everything away and starting over!</div>
<div><br></div><div>I have spent the last 10 years optimizing software for a living, and can tell you without a doubt that any system can be optimized without starting from scratch.  </div><div><br></div><div>It's just much harder to understand the performance characteristics of a large, complex, existing system than it is to imagine an ideal performance world in your head.</div>
<div><br></div><div>Best regards,</div><div>Wade </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><p></p>
<p>Best regards,</p><p>                            Tiago Marques</p>
</blockquote></div><br>