<div dir="ltr">Concrete data and actionable tasks would help.<div>Please share your profiling when you have it.</div><div><br></div><div>Gonzalo</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Nov 19, 2013 at 3:08 AM, Sebastian Silva <span dir="ltr"><<a href="mailto:sebastian@fuentelibre.org" target="_blank">sebastian@fuentelibre.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div>Hi Daniel,<br>
      <br>
      Thanks for your thoughtful answer. I reply inline to the issues
      raised.<br>
      <br>
      El 18/11/13 08:30, Daniel Narvaez escribió:<br>
    </div><div class="im">
    <blockquote type="cite">Hi Sebastian,
      <div><br>
      </div>
      <div>It would be really useful if you could give some more
        informations on the performance issues you have been seeing</div>
      <div><br>
      </div>
      <div>- What is slow exactly?</div>
    </blockquote></div>
    Initial startup, switch between activities, activity startup. Also
    probably redraw after widget damage e.g. the Frame appears. Then
    again it's hard to pinpoint exactly, just out of memory now.<div class="im"><br>
    <blockquote type="cite">
      <div>- Why do you believe it's an issue with low level libraries
        (and which libraries)?</div>
    </blockquote></div>
    I like to dogfood. I do all my work on a low end atom netbook. I
    have observed in my own use how applications ported to GTK3 have
    degraded performance (e.g. Evince, Gnumeric). I have come to expect
    this, really as I experienced the same thing when moving as a user
    from GTK1 to GTK2.<br>
    <blockquote type="cite">
      <div>- Did you profile?</div>
    </blockquote>
    Nope, but our images are still in beta and I'd be willing to profile
    and share the results by default. If it will help then we can have a
    metric.<div class="im"><br>
    <blockquote type="cite">
      <div><br>
      </div>
      <div>Please don't assume people knows what they are talking about
        when they speak about performance, unless they back up their
        claims with profiling data, especially if they are
        just saying things are "lighter" and base a toolkit switch on
        that!</div>
    </blockquote>
    <br></div>
    I'm sure that they at least carefully measured the memory usage. On
    XO1 this is critical with only 256mb ram. Also the OS by default has
    no swap.<div class="im"><br>
    <blockquote type="cite">
      <div><br>
      </div>
      <div>I know fairly well what changed between gtk2 and gtk3 and I
        have a very very hard time believing it introduced unfixable
        regressions. By design things should have improved, as far as I
        know. The problem is probably more that, as usual, the
        performance of the system developers works with has improved,
        thus with changes comes regressions that are not noticed. And
        the only way to counter that is to profile and fix the
        real issues...</div>
    </blockquote></div>
    Understood. However it's a little out of my league, I admit. I tend
    to focus on serving low hanging fruit in a user friendly plate. This
    is why distributions interest me so much.<div class="im"><br>
    <blockquote type="cite">
      <div><br>
      </div>
      <div>I'm personally going to focus on newer hardware, but then
        isn't  XO 1 most of our user base currently? It seems we need to
        balance research and continued support here... Also note that
        the new hardware isn't going to be blazing fast either, the
        issue we find there are most likely very similar to the ones on
        the XO 1, just to a lesser scale. If we improve XO 1, other
        hardware will most likely improve too.</div>
    </blockquote></div>
    Yes, only in newer hardware the impression that the Sugar user
    experience is not very good is not really related to performance, or
    at least, not primarily.<div class="im"><br>
    <blockquote type="cite">
      <div><br>
      </div>
      <div>I think we need to get much better collectively at working on
        performance, it's a key aspect of the kind of hardware we are
        targeting and my feeling is that a lot of people don't like
        Sugar mostly because it's so slow...</div>
    </blockquote></div>
    A platform is about the applications available to it. Sugar in my
    opinion has issues here as well. I tend to concur with Flavio that
    some aesthetics rework wouldn't hurt either. For what it's worth I
    always found interesting what the advertising firm that worked on
    Sugar published in their website:
    
    <a href="http://new.pentagram.com/2006/12/new-work-one-laptop-per-child/" target="_blank">http://new.pentagram.com/2006/12/new-work-one-laptop-per-child/</a><br>
    <br>
    On the topic of aesthetics, it's interesting to see what even
    happens with adding a compositor (in metacity's gconf key) and
    changing some colors in style.py<br>
    I recently noticed that in ancient versions (pre 0.82) the Journal
    items were separated with a thin line. This helped readability and
    gave the sense that each line was an object.<br>
    <br>
    Maybe I just went off topic (again) but now that we are sharing...<br>
    <blockquote type="cite">
      <div>
        <div><br><span class="HOEnZb"><font color="#888888">
        </font></span></div><span class="HOEnZb"><font color="#888888">
      </font></span></div><span class="HOEnZb"><font color="#888888">
      -- <br>
      Daniel Narvaez<br>
      <br>
    </font></span></blockquote>
    <br>
  </div>

</blockquote></div><br></div>