Thursday 4 May 2006
Assorted Thoughts
As a vehement opponent of monopolies, I am glad to see that the New Zealand government is taking a hard line against our local telecommunications monopoly. Yay!
The news from Iran gets increasingly more depressing. I'm amazed nuclear weapon technology has been contained as well as it has for the last sixty years ... just think, nuclear weapons are nearly as old as television and older than general-purpose computers. But the nuclearization of India, Pakistan, North Korean, and now --- seemingly inevitably --- Iran may indicate that we're reaching a tipping point. I just can't see a good future for a world of loose nukes. New Zealand may be one of the best places to be, but that's not saying much. Christians, start your prayers.
I've been fixing random Mozilla bugs lately, mostly regressions plus a few security/stability issues. I've also been spending a lot of time reviewing Darin's event/thread rewrite. It's great stuff which will simplify our code, fix a lot of bugs, and seems to improve performance.
Over the last few months I've also reviewed a lot of SVG fixes --- the SVG issues that I highlighted in February are largely fixed! A lot of the remaining performance issues are lower-level problems with cairo and platform-specific rendering code.
Now that SVG is getting cleaned up, I'm hopeful that Brian Birtles and the rest of the SVG crew will be able to look at updating and landing Brian's SMIL animation patch without much more delay.
I'm trying to finally land a patch which will unify all documents into a single view manager hierarchy. This will let you do things like have the browser stack translucent XUL elements over content windows. Every time I try to land it, we encounter performance problems, and my attempt tonight did too, so I backed it out. I did gather some data so hopefully I'll be able to figure out what the problem is and get it right.
I've started working on pulling plugin windows up to the top-level window. We should be able to do it in a way that also lets us compute visibility information for plugin windows, so you can have a DIV with a solid background actually render on top of the plugin window --- by clipping a hole in the window where the DIV needds to appear. It's not hard in theory but as usual the devil is in the details, getting reasonable performance and dealing with fallout from touching the fragile, platform-specific plugin handling code.
I've installed SuSE Linux Enterprise Desktop 10 (hope I got that right!) on my desktop and laptop. It's very slick. Xgl and compiz look fantastic on my laptop, and work flawlessly with my ATI graphics hardware, but I've had some problems with my desktop's NVidia setup ... this is ironic because NVidia has usually been considered reliable and ATI the problem child of Linux graphics drivers. I have to say that due to some combination of Xgl, compiz, the fonts, the default theme, and my laptop's high-density screen, my laptop now has the sexiest-looking graphical environment that I've ever used (and I'm writing this on an iMac at home). I wonder what more Windows Vista will offer that required Microsoft to dictate massive changes to their graphics stack and onerous hardware requirements, not to mention spend so much time developing the thing.
One thing that I really like about compiz that you don't see in the demos is that it grays out windows that aren't responding to events (a lovely effect, it makes the window a little darker and turns it black-and-white). This is a real usability win; you know that the application is not going to be responsive, so you don't keep clicking on it in hope, and there's no uncertainty about "maybe it didn't work because I clicked in the wrong place". Even better, you can see when it becomes usable again without having to periodically click on it to check.
One effect is still missing ... applications that crash just disappear abruptly. Abrupt shutdown should make the application's window explode in a realistic particle simulation.
Another Mozilla thing I'm planning to work on soon is getting the new textframe code into the tree so we can get people working on improving it in multiple directions. Before I do that I want to simplify the way textframes and inline reflow handle some corner cases, which I'll talk about in another blog post.
Update: By popular demand, I've made a screenshot. Because a great deal of the sexiness is the animation, you really need a video, something I can't be bothered doing (and which would probably get me booted off weblogs.mozillazine.org). All you can see here is the obligatory cube in action, plus window drop shadows and translucent window borders. Because the cube sides are lit, the actual desktop is considerably brighter than you see here.
Here's another showing the desktop in normal mode. Here I've stopped the OpenOffice process to demonstrate the grayed-out effect.
The news from Iran gets increasingly more depressing. I'm amazed nuclear weapon technology has been contained as well as it has for the last sixty years ... just think, nuclear weapons are nearly as old as television and older than general-purpose computers. But the nuclearization of India, Pakistan, North Korean, and now --- seemingly inevitably --- Iran may indicate that we're reaching a tipping point. I just can't see a good future for a world of loose nukes. New Zealand may be one of the best places to be, but that's not saying much. Christians, start your prayers.
I've been fixing random Mozilla bugs lately, mostly regressions plus a few security/stability issues. I've also been spending a lot of time reviewing Darin's event/thread rewrite. It's great stuff which will simplify our code, fix a lot of bugs, and seems to improve performance.
Over the last few months I've also reviewed a lot of SVG fixes --- the SVG issues that I highlighted in February are largely fixed! A lot of the remaining performance issues are lower-level problems with cairo and platform-specific rendering code.
Now that SVG is getting cleaned up, I'm hopeful that Brian Birtles and the rest of the SVG crew will be able to look at updating and landing Brian's SMIL animation patch without much more delay.
I'm trying to finally land a patch which will unify all documents into a single view manager hierarchy. This will let you do things like have the browser stack translucent XUL elements over content windows. Every time I try to land it, we encounter performance problems, and my attempt tonight did too, so I backed it out. I did gather some data so hopefully I'll be able to figure out what the problem is and get it right.
I've started working on pulling plugin windows up to the top-level window. We should be able to do it in a way that also lets us compute visibility information for plugin windows, so you can have a DIV with a solid background actually render on top of the plugin window --- by clipping a hole in the window where the DIV needds to appear. It's not hard in theory but as usual the devil is in the details, getting reasonable performance and dealing with fallout from touching the fragile, platform-specific plugin handling code.
I've installed SuSE Linux Enterprise Desktop 10 (hope I got that right!) on my desktop and laptop. It's very slick. Xgl and compiz look fantastic on my laptop, and work flawlessly with my ATI graphics hardware, but I've had some problems with my desktop's NVidia setup ... this is ironic because NVidia has usually been considered reliable and ATI the problem child of Linux graphics drivers. I have to say that due to some combination of Xgl, compiz, the fonts, the default theme, and my laptop's high-density screen, my laptop now has the sexiest-looking graphical environment that I've ever used (and I'm writing this on an iMac at home). I wonder what more Windows Vista will offer that required Microsoft to dictate massive changes to their graphics stack and onerous hardware requirements, not to mention spend so much time developing the thing.
One thing that I really like about compiz that you don't see in the demos is that it grays out windows that aren't responding to events (a lovely effect, it makes the window a little darker and turns it black-and-white). This is a real usability win; you know that the application is not going to be responsive, so you don't keep clicking on it in hope, and there's no uncertainty about "maybe it didn't work because I clicked in the wrong place". Even better, you can see when it becomes usable again without having to periodically click on it to check.
One effect is still missing ... applications that crash just disappear abruptly. Abrupt shutdown should make the application's window explode in a realistic particle simulation.
Another Mozilla thing I'm planning to work on soon is getting the new textframe code into the tree so we can get people working on improving it in multiple directions. Before I do that I want to simplify the way textframes and inline reflow handle some corner cases, which I'll talk about in another blog post.
Update: By popular demand, I've made a screenshot. Because a great deal of the sexiness is the animation, you really need a video, something I can't be bothered doing (and which would probably get me booted off weblogs.mozillazine.org). All you can see here is the obligatory cube in action, plus window drop shadows and translucent window borders. Because the cube sides are lit, the actual desktop is considerably brighter than you see here.
Here's another showing the desktop in normal mode. Here I've stopped the OpenOffice process to demonstrate the grayed-out effect.
Comments
Great idea!
The exploding windows would be just too cool. But they might scare people :)
The blatant hypocrisy of the USA and UN Security Council in deciding whom to sanction and whom to ignore provides convenient moral cover for any country developing nuclear arms. Every country with nuclear weapons (http://en.wikipedia.org/wiki/List_of_countries_with_nuclear_weapons) needs to show that it's serious about reducing its arsenal, and open up to full inspection. South Africa dismantled its nukes, it can be done!
Thanks for all the Mozilla patch review work!
At this point complete disarmament would be quite dangerous even if it could be achieved, because we don't want one rogue state to take nuclear supremacy (and I include the US!). And I don't know that it matters much if the USA, Russia and China have 100 nukes or 10000. There is hypocrisy, but the "moral cover" is weak, a story mostly trotted out by villains.
About the desktop ... there are plenty of screenshots around the net, but you really need videos to experience the coolness, and I don't have the time to learn how to make them. Sorry!
We currently have an XPCOM abstraction for threads, and an XPCOM abstraction for event queues, which contain PLEvents that aren't actually XPCOM objects. There's actually a stack of event queues for each thread, this was introduced to allow you to temporarily suspend normal event processing but still process some events while you do some synchronous, long-running operation. For various reasons that doesn't actually work and is merely a source of performance problems and bugs. Darin's work eliminates the event queue stack, folds event processing directly into the thread objects, simplifies the APIs a lot, adds helpers for the common operations, and makes events true ref-counted XPCOM objects which actually makes them much easier to use.
It would be really nice to have a separate blog post disseminating the leasons learned (explaining in much more detail why this approach doesn't work).
Thanks for the screenshots BTW. :-)