News on the 3.0.2 release

From Ian Pratt as seen on xen-devel:

"We were just going to sweep -unstable into -testing and call a 3.0.2 release, but it was felt that since there had been some significant changes in the previous few days letting it sit in unstable for a few days wouldn't be a bad thing."

Just in case you were wondering...

Xen 3.0.2 will be going out soon

I dropped my latest (and hopefully final) version of the XML-RPC enablement for Xend this afternoon. The XML-RPC support is one of the last features to be merged before the 3.0.2 release so I expect we'll see 3.0.2 go out sometime this week.

I'm quite happy that we're actually keeping to our 4-8 week release cycle. Unfortunately, we're probably going to slip a tiny regression into the 3.0.2 release. Last week, I noticed that our block-attach code is failing. Apparently, we had some problems in our test suite that were masking the fact that it has been failing for quite some time now. block-attach isn't an extremely important feature so I don't think it's something that will hold up 3.0.2 but it would be nice to fix before releasing.

I'm pretty sure it's hotplug related. Our use of hotplug for device bring up definitely has been a pain for us. Hopefully Rusty's new drivers won't require these sort of things and we'll hopefully gain some robustness.

Xgl is now my default desktop

I finally got around to figuring out why emacs wouldn't start. Now it will. The only thing left that would make things just perfect is if I could figure out how to have compiz start automatically.

Getting NetworkManager to work under Dapper

Just FYI, if you have a network interface configured in /etc/network/interfaces then the new NetworkManager won't touch it.

I've been racking my brain for weeks over this one (well not really).

Some times you just have to derive it yourself

I've got my shared memory QEMU interface working really well. So well, in fact, that I'm looking for the next hard thing to do. One of the neatest features of my old QEMU GTK gui was that it supported software scaling using GDK pixbuf.

GDK pixbuf is kind of annoying though because it's a client side image. The scaling code in GDK is very pixbuf specific too. Also, I never was able to figure out how to do partial updates of a scaled image without getting artifacts.

Last night I started reading about bilinear scaling. The first thing I learned is that is not really scaling, but filtering, but not really filtering, actually interpolation. Last night I finally came across a site that gave a good explaination of it in terms of graphics but lacked the math. The only sites that I found that had the math provided it in either a heavily solved form (solving for different things that I was looking for mind you) or just made no sense at all.

This morning, I decided to see about deriving this myself so that I'd actually understand it. The idea is pretty simple, given a point of unknown color that lies in the middle of four points of known color, calculate relative distance from each known point to the unknown point. Then use the distances (with the total distance of all points normalized to 1) as a factor for each known color and simply sum the known colors to obtain the unknown colors.

This may sound obtuse but it's really intuitive when you see it in action. It's just saying that the closer an unknown point is to a known point, the more that known point's color should contribute to the unknown point's color.

Know that I understand the algorithm and have an implementation, I've thought of many interesting optimizations. For instance, the amount that a known point contributes to an unknown point is orthagonal to the actual color of the known points. This means it can be computed once. This reduces the actual operations per update to 4 multiples and 5 adds per pixel. This seems like the sort of thing that I should be doing with MMX so I'll be looking into that.

The other part of this algorithm that requires computation is determining which known points surround an unknown point. The cool thing here is that this not only independent of the color of the pixels but computing the X coordinates of the known points given an unknown point's X coordinate is independent of the Y coordinates of the unknown point and vice versa. This means that it can be precompute once for a single row and then once for a single column! That requires very little memory (which is good because I'm slightly concerned that caching the color factors will take up an enormous amount of memory).

Fun stuff!