More on themes, and on why Human’s slow

On The RocksFour points of note in theming today.  Your thoughts on these, gentle reader, are appreciated.

  1. Screwtape has been working on a Metacity theme to look like Mac OS Classic.  The resulting list of tips and tricks for writing Metacity themes ought to be required reading for all themers.  Screwtape, would you mind if we linked to it from the sidebar of this blog?
  2. I have added a small amount of optimisation to line drawing:  if a line is horizontal or vertical, the second x or y coordinate is not stored, and if a line’s beginning and ending coordinates are identical, neither the second x nor the second y coordinate are stored, and the line is drawn as a point.  This seems to have sped things up a little.  (Note, by the way, that speeding up Metacity themes will also help Compiz along too.)
  3. As a followup to my previous post about Human, I have checked to see what part of drawing the gradient is so slow.  The results are clear: preparing the bitmap is fast, and painting it is slow.  Almost the whole wait is  taken up with the call to gdk_draw_pixbuf()The docs contain a stern warning:

    On older X servers, rendering pixbufs with an alpha channel involves round trips to the X server, and may be somewhat slow.

    Since all the gradients have an alpha channel, I am led to wonder whether the delay is caused by this problem, and what possible workarounds there might be. (Update: But removing the alpha channel doesn’t make much of a difference, so maybe it’s just that painting this large an area is inherently slow.  I wonder whether we can create a 1xn pixel tile instead and tile it along the length of the area, and whether that would be faster.)

  4. The RPN version of the expression parser is rather faster than the existing parser, and (I believe) simpler to understand, but expression parsing is not a major timesink at present anyway, so it saves at most a few hundred microseconds per frame draw.  I am wondering whether merging it is worth the chance that it might misinterpret some theme somewhere.  Perhaps now immediately after a branch is the best time to consider it, though.

Photo © Auntie K, cc-by.

4 Comments

  1. Screwtape
    Posted February 8, 2009 at 3:57 am | Permalink

    Screwtape, would you mind if we linked to it from the sidebar of this blog?

    By all means, go ahead – if somebody wanted to summarize that (surprisingly long) screed into some kind of official documentation, all the better. :)

    (in case anyone’s interested, the theme in question can now be downloaded here)

  2. Screwtape
    Posted February 8, 2009 at 11:30 am | Permalink

    Also, you seem to have some kind of log-with-timestamps-to-SVG script. Is that publicly available?

  3. BrettA
    Posted February 13, 2009 at 4:29 am | Permalink

    So how will the Human theme be updated this time around (for 9.04)?

  4. Posted March 7, 2009 at 10:33 pm | Permalink

    @Screwtape:

    Posted the script here.

2 Trackbacks

  1. [...] Thurman: More on themes, and why Human’s slow. In my last links post I had a link to a post by Thomas about why the Human theme (Ubuntu’s [...]

  2. By So, why is Human slow? - …for the adult in you on March 7, 2009 at 10:26 pm

    [...] …for the adult in you “Many window managers are like Marshmallow Froot Loops; Metacity is like Cheerios.” Skip to content « More failed experiments in theming More on themes, and on why Human’s slow » [...]