alex is currently certified at Master level.

Name: Alexander Larsson
Member since: 2000-02-28 22:46:26
Last Login: N/A

FOAF RDF Share This

Homepage: http://www.lysator.liu.se/~alla

Notes:

I work in the Desktop group at Red Hat, where I'm mainly involved with Gnome. I'm one of the primary maintainers of Nautilus, the Gnome file manager. I also maintain gnome-vfs and various other smaller Gnome modules. I've been involved in many free software projects over the years, and i've even started a few, such as Dia.

Projects

Recent blog entries by alex

Syndication: RSS 2.0

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.

17 Dec 2004 (updated 17 Dec 2004 at 16:24 UTC) »

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.

16 older entries...

 

alex certified others as follows:

  • alex certified jamesh as Master
  • alex certified blizzard as Master
  • alex certified ramiro as Journeyer
  • alex certified pavlov as Journeyer
  • alex certified shaver as Master
  • alex certified davem as Master

Others have certified alex as follows:

  • dan certified alex as Journeyer
  • harold certified alex as Journeyer
  • goran certified alex as Journeyer
  • bombadil certified alex as Journeyer
  • blizzard certified alex as Master
  • jochen certified alex as Master
  • duncan certified alex as Journeyer
  • ole certified alex as Master
  • graydon certified alex as Journeyer
  • dwmw2 certified alex as Journeyer
  • asmodai certified alex as Journeyer
  • jamesh certified alex as Master
  • digdude certified alex as Master
  • camber certified alex as Master
  • gazook certified alex as Master
  • AustinBlues certified alex as Master
  • MattyT certified alex as Master
  • grem certified alex as Master
  • menthos certified alex as Master
  • pawal certified alex as Journeyer
  • sh certified alex as Journeyer
  • Thias certified alex as Master
  • hub certified alex as Master
  • andersca certified alex as Master
  • bratsche certified alex as Master
  • MCArkan certified alex as Master
  • jao certified alex as Master
  • zilch certified alex as Master
  • ricardo certified alex as Master
  • cinamod certified alex as Master
  • dsandras certified alex as Master
  • lypanov certified alex as Master
  • funrecords certified alex as Master
  • hadess certified alex as Master
  • larsrc certified alex as Master
  • gicmo certified alex as Master
  • fxn certified alex as Master
  • roozbeh certified alex as Master
  • pvanhoof certified alex as Master
  • behdad certified alex as Master
  • kclayton certified alex as Master
  • adl certified alex as Master

[ Certification disabled because you're not logged in. ]

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

X
Share this page