Since planet gnome is not updated yet to my new blog, here is my thoughs on the recent "is gnome fun" discussion, copied from my blog:

Are language discussions fun?

I'm not sure how the "is Gnome fun" discussion turned into a language discussion. I would personally perfer using either C# or Java over C to code a new app these days. However, using C is not what makes hacking Gnome less fun than it used to be for me.

What makes Gnome less fun for me is the fact that Gnome is a stable high-quality codebase that I'm spending all my time maintaining. Each little change has to be very careful about not breaking backwards compatibility or introducing bugs and each new features must be very well understood and known to be right (because its very hard to get rid of it later). Most time I spend on gnome is reading bugzilla, fixing bugs in old code, discussing each little change forever, reviewing patches and saying no to feature requests. In essence, I have become a maintainance programmer, not a software developer. Of course, at times I do new development, but it is far more seldom than it used to be, and I almost never have time to do experimental stuff.

One reason using C# or Java would make things fun for me is because it would basically force me to work on a new application from scratch, which means I wouldn't have to care about all these things and just go wild experimenting and hacking. Of course, there isn't much chance for me to do that because even if I did start working on a new app I'd still have all the old code I'd have to maintain.

I have moved my blog to blogs.gnome.org.

pcolijn: The mime system is described at http://www.gnome.org/~jrb/files/mime/

Uraeus:
Interestingly enough, the Swedish media is full of discussions about how slow the swedish government was to react to the tsunami catastrophe. And I heard a guy on radio saying that the Finnish papers were saying the same thing (complaining how much faster the swedish government acted).

I guess its typical scandinavian to blame the government for everything.

I've been playing with cairo and xpdf the last few days, trying to make a cairo-based backend for xpdf. That should allow nice antialiased graphics and eventually full PDF 1.3 transparency support.

However, when I tried to render a page in a PDF file I had lying around it was rendering very slowly. I know the Cairo authors have said that they're focusing on design and correctness for now, and that there are lots of optimizations that are not yet done. However, I was getting rendering speeds of a few characters per second, and the full page took 4 minutes and 30 seconds to render. Clearly something was wrong.

So, I fired up the profiler to get a better understanding of what was going wrong. It appears that I was using a non-rectangular clip region, which in Cairo is implemented by an alpha buffer (called the clip surface) that is used as a mask when drawing to the target. When drawing a glyph cairo was allocating a temporary image for drawing the glyph into. Unfortunately it was allocating a termporary buffer the same size as the clip surface, even though the glyph drawn into it was much smaller. In my case, the clip surface was 1240x1754 pixels!

I fixed this in several places so that it only allocated the smallest temporary buffer needed. Rendering was a lot faster now, but profiling showed another large slowdown. When clearing the clip surface and temporary buffers it was somehow using the super-generic pixel compositing functions! I looked into this and discovered that the libpixman solid rectangle fill functions were disable since they were not implemented yet.

After implementing solid rectange fills I was now down to 2.42 seconds for rendering the PDF page. Thats a speedup of over 10000%, in just a days work! I've sent the patches to the cairo list, and I hope they'll get applied soon.

Sometimes optimization is extremely hard. I've personally spent years trying to make Nautilus faster. Its gotten better, but its very hard work. But for software in their early stages of life, optimization is a fun and very rewarding excercise.

In the end I also looked into why it was using the clip surface so much, and it turns out that the page size (crop box) of the page when transformed to device coordinates didn't end up on integer coordinates. This meant cairo had to use a clip surface for the whole page, just to clip the last half a pixel of the rightmost column. By tweaking the crop box to have integer coordinates I got another 400% speedup. And it even looks better than with the original clipping.