On In-Kernel Drivers
It’s pretty well-known that the Linux kernel developers advocate getting your drivers into the main line kernel tree. Doing so ensures that your driver always gets fixed to conform to the latest “correct” internal interfaces when they change, and in-kernel device drivers always get distributed with the kernel, so you get automatic end-user distribution for free.
While I agree with that (without touching the question of whether or not a stable driver binary API/ABI would be useful), I’m not entirely sure it’s the best thing in the world for some types of device drivers.
While reading a post by Carl Worth on recent (perceived?) driver stability issues with the Intel video driver for Linux, I came across this bit of insight:
It used to be that getting the latest Intel driver just meant updating an xf86-video-intel module or upgrading an xserver-xorg-video-intel package. But now it’s essential to get a recent kernel as well… And these fixes aren’t in a major kernel release until 2.6.30 which appeared only today.
This is a problem that perhaps highlights some types of drivers that may be served better by being maintained outside the main line Linux kernel tree. Of course, this is only true while the driver is actively maintained and maintainers are able to quickly update the driver for new kernels (without breaking backward compatibility) as in-kernel interfaces change.
He also notes that distribution maintainers tend to update critical parts of the system (like the kernel) less often than userspace portions (like X.org video drivers). Since the xorg-video-intel driver depends on an in-kernel driver, it’s easy for these two things to become out of sync on an end-user’s system without testing. Or, frustratingly, the maintainer of the userspace package for a video driver might be unable to update to a newer version of the userspace driver because the kernel packager doesn’t wish to upgrade the entire kernel to become compatible with that userspace package (which is an entirely reasonable position to take).
And with more video drivers expected to move toward having significant kernel portions, this problem can only get worse. What if the latest userspace package for drivers A and B both depend on kernel 2.6.30, and the maintainer of package A wants to update, but the package B maintainer doesn’t (perhaps there’s a bad bug in the latest version of B)? Even if the A package maintainer can convince the kernel maintainer to update, doing so might break things for other users.
Now, sure, having dependency issues like that is nothing new, but I submit that this is a bit different. The kernel contains so much “unrelated” functionality that it has the potential to be a root dependency of many unrelated packages. For example, if a video player depends on a particular version of a codec library, you can often update that codec library without causing issues with other video players (ignoring, for a moment, ffmpeg’s inability to maintain a stable API). But updating the kernel because a userspace video driver requires a new kernel version could potentially cause problems with anything ranging from a USB storage device, to a hard disk controller, to an audio card.
Now, of course, the Intel video driver has been undergoing some very large changes lately. In theory, these things will settle down, interfaces will stabilize, and you can expect the tight coupling between the kernel version and userspace package version to relax a bit. But perhaps during this transition period it might make sense to avoid merging kernel code like this at all, and instead do separate releases of (in this case) the DRM modules that are paired to the userspace package. I imagine it wouldn’t be too much of a burden for distro packagers to disable building the in-kernel versions of these drivers, and instead ship an extra module package that the userspace driver packages can depend on.
On In-Kernel Drivers
It's pretty well-known that the Linux kernel developers advocate getting your drivers into the main line kernel tree. Doing so ensures that your driver always gets fixed to conform to the latest "correct" internal interfaces when they change, and in-kernel device drivers always get distributed with the kernel, so you get automatic end-user distribution for free.
While I agree with that (without touching the question of whether or not a stable driver binary API/ABI would be useful), I'm not entirely sure it's the best thing in the world for some types of device drivers.
While reading a post by Carl Worth on recent (perceived?) driver stability issues with the Intel video driver for Linux, I came across this bit of insight:
It used to be that getting the latest Intel driver just meant updating an xf86-video-intel module or upgrading an xserver-xorg-video-intel package. But now it's essential to get a recent kernel as well... And these fixes aren't in a major kernel release until 2.6.30 which appeared only today.
This is a problem that perhaps highlights some types of drivers that may be served better by being maintained outside the main line Linux kernel tree. Of course, this is only true while the driver is actively maintained and maintainers are able to quickly update the driver for new kernels (without breaking backward compatibility) as in-kernel interfaces change.
He also notes that distribution maintainers tend to update critical parts of the system (like the kernel) less often than userspace portions (like X.org video drivers). Since the xorg-video-intel driver depends on an in-kernel driver, it's easy for these two things to become out of sync on an end-user's system without testing. Or, frustratingly, the maintainer of the userspace package for a video driver might be unable to update to a newer version of the userspace driver because the kernel packager doesn't wish to upgrade the entire kernel to become compatible with that userspace package (which is an entirely reasonable position to take).
And with more video drivers expected to move toward having significant kernel portions, this problem can only get worse. What if the latest userspace package for drivers A and B both depend on kernel 2.6.30, and the maintainer of package A wants to update, but the package B maintainer doesn't (perhaps there's a bad bug in the latest version of B)? Even if the A package maintainer can convince the kernel maintainer to update, doing so might break things for other users.
Now, sure, having dependency issues like that is nothing new, but I submit that this is a bit different. The kernel contains so much "unrelated" functionality that it has the potential to be a root dependency of many unrelated packages. For example, if a video player depends on a particular version of a codec library, you can often update that codec library without causing issues with other video players (ignoring, for a moment, ffmpeg's inability to maintain a stable API). But updating the kernel because a userspace video driver requires a new kernel version could potentially cause problems with anything ranging from a USB storage device, to a hard disk controller, to an audio card.
Now, of course, the Intel video driver has been undergoing some very large changes lately. In theory, these things will settle down, interfaces will stabilize, and you can expect the tight coupling between the kernel version and userspace package version to relax a bit. But perhaps during this transition period it might make sense to avoid merging kernel code like this at all, and instead do separate releases of (in this case) the DRM modules that are paired to the userspace package. I imagine it wouldn't be too much of a burden for distro packagers to disable building the in-kernel versions of these drivers, and instead ship an extra module package that the userspace driver packages can depend on.
On In-Kernel Drivers
It’s pretty well-known that the Linux kernel developers advocate getting your drivers into the main line kernel tree. Doing so ensures that your driver always gets fixed to conform to the latest “correct” internal interfaces when they change, and in-kernel device drivers always get distributed with the kernel, so you get automatic end-user distribution for free.
While I agree with that (without touching the question of whether or not a stable driver binary API/ABI would be useful), I’m not entirely sure it’s the best thing in the world for some types of device drivers.
While reading a post by Carl Worth on recent (perceived?) driver stability issues with the Intel video driver for Linux, I came across this bit of insight:
It used to be that getting the latest Intel driver just meant updating an xf86-video-intel module or upgrading an xserver-xorg-video-intel package. But now it’s essential to get a recent kernel as well… And these fixes aren’t in a major kernel release until 2.6.30 which appeared only today.
This is a problem that perhaps highlights some types of drivers that may be served better by being maintained outside the main line Linux kernel tree. Of course, this is only true while the driver is actively maintained and maintainers are able to quickly update the driver for new kernels (without breaking backward compatibility) as in-kernel interfaces change.
He also notes that distribution maintainers tend to update critical parts of the system (like the kernel) less often than userspace portions (like X.org video drivers). Since the xorg-video-intel driver depends on an in-kernel driver, it’s easy for these two things to become out of sync on an end-user’s system without testing. Or, frustratingly, the maintainer of the userspace package for a video driver might be unable to update to a newer version of the userspace driver because the kernel packager doesn’t wish to upgrade the entire kernel to become compatible with that userspace package (which is an entirely reasonable position to take).
And with more video drivers expected to move toward having significant kernel portions, this problem can only get worse. What if the latest userspace package for drivers A and B both depend on kernel 2.6.30, and the maintainer of package A wants to update, but the package B maintainer doesn’t (perhaps there’s a bad bug in the latest version of B)? Even if the A package maintainer can convince the kernel maintainer to update, doing so might break things for other users.
Now, sure, having dependency issues like that is nothing new, but I submit that this is a bit different. The kernel contains so much “unrelated” functionality that it has the potential to be a root dependency of many unrelated packages. For example, if a video player depends on a particular version of a codec library, you can often update that codec library without causing issues with other video players (ignoring, for a moment, ffmpeg’s inability to maintain a stable API). But updating the kernel because a userspace video driver requires a new kernel version could potentially cause problems with anything ranging from a USB storage device, to a hard disk controller, to an audio card.
Now, of course, the Intel video driver has been undergoing some very large changes lately. In theory, these things will settle down, interfaces will stabilize, and you can expect the tight coupling between the kernel version and userspace package version to relax a bit. But perhaps during this transition period it might make sense to avoid merging kernel code like this at all, and instead do separate releases of (in this case) the DRM modules that are paired to the userspace package. I imagine it wouldn’t be too much of a burden for distro packagers to disable building the in-kernel versions of these drivers, and instead ship an extra module package that the userspace driver packages can depend on.
Preview: Browsing SFTP with Thunar
It feels like I'm finally getting somewhere. My GIO migration branch of Thunar now generates thumbnails using the D-Bus service provided by Tumbler (which is still in development but almost ready for a release). It has no references to ThunarVFS anymore, except for one function required by Thunarx, the Thunar extension library. The next step will be to prepare thunarx-2 with a ThunarVFS-free API. All plugins shipped with Thunar itself need to be updated. ThunarVFS will be moved out of the Thunar tarball and into its own, so that applications depending on it will still work. And then we only need to fork the HAL based volume monitor from GVfs and of course thunar-volman needs to be rewritten on top of GIO ...
Anyway, just a few moments ago, I did something I thought is worth sharing: I browsed one of our servers remotely over SFTP! Mounting still needs to be done from the terminal but after that, you can simply type in the SSH or SFTP URI and it will display its contents. Thumbnails are generated over D-Bus. Here's a screenshot:
Update
Thunar can now mount remote URIs on demand:
FTP browsing also works:
On In-Kernel Drivers
It’s pretty well-known that the Linux kernel developers advocate getting your drivers into the main line kernel tree. Doing so ensures that your driver always gets fixed to conform to the latest “correct” internal interfaces when they change, and in-kernel device drivers always get distributed with the kernel, so you get automatic end-user distribution for [...]Xfce4 Screenshooter 1.6.0
I'm pleased to announce the 1.6.0 release of Xfce4 Screenshooter. This cycle was quite long because I had some exams and the number of implemented features is bigger than usual.
First, there is a brand new interface based on a review by Fabrice Viale : it is simpler and more polished. This new interface also allows you to choose whether the mouse cursor should be captured and whether the application should be closed after taking the screenshot. Here is a screenshot of the application:
It is now possible to save screenshots on any remote share supported by GVFS: ftp, sftp, samba... You just need to connect to a share or a distant computer using Gigolo or gvfs-connect and it will be displayed in the sidebar of the save dialog.
This release also features the possibility to host screenshots online, on ZimageZ. You just need to set up an account on their website and you will then be able to upload your screenshots to ZimageZ directly from Xfce4 Screenshooter. This feature is still a bit experimental and will be improved in the next release: for example accents in the user name or password cause a fail during the upload...
There are also some other small changes which can be found in the changelog. I would like to thank Jannis Pohlmann (for his help concerning jobs and threads), Fabrice Viale (for his interface review), Mike Massonnet and Enrico Tröger (for their various patches) ,Yves-Alexis Perez and Ali Abdallah (for the testing and the suggestions). And last but not least, the translation team who did a great job by adding and updating a lot of translations of the application and of the documentation.
Benchmarks: gtk+ engines revisited
Six months ago I posted some benchmarks of popular gtk+ engines. It's time to revisit those benchmarks and test the engines again, this time using FOSS drivers for my new hardware.
Today I installed my brand-spankin' new graphics card, an ATI RadeonHD 4550, by Sapphire. Getting working 2D acceleration with EXA was a cinch, now that the 2.6.30 kernel is out. Doesn't require anything special in terms of packages; nothing from overlays or bleeding-edge git checkouts. Only needs three ~arch packages: gentoo-sources, libdrm, and mesa.
For this updated round of testing, I used the same gtk+ engines, but also added some new ones. These can all be obtained by installing the following packages: gtk-engines, gnome-themes, gtk-engines-aurora, gtk-engines-candido, gtk-engines-rezlooks, and gtk-engines-xfce. New to the testing list are the Crux, ThinIce, HighContrast, and Redmond95 engines.
Once again, gtkperf-0.40 was used to obtain these benchmarks. With the exception of the graphics hardware and driver, the testing environment is mostly the same. Xfce has been updated to 4.6.1.
Let's see how all these engines perform on my Xfce workstation, eh?
Notes on the hardware:
CPU: Athlon 64 X2 4600+
Graphics: ATI RadeonHD 4550, DVI 1440x900 @ 60Hz
RAM: 4GB DDR2-667
Mobo: ASUS M3N78-VM
Notes on the testing environment:
OS: Gentoo Linux (duh)
Kernel: Linux 2.6.30-gentoo-r1 #1 SMP PREEMPT x86_64
xf86-video-ati: 6.12.1-r1
CFLAGS: -march=athlon64-sse3 -O2 -fomit-frame-pointer
DE: Xfce 4.6.1
- Xfwm4 with Composite enabled, effects: drop shadows & transparency
- Open applications: 2 instances of x11-terms/terminal
Custom themes are noted with *. These are personal themes I've made, nothing more than simple color modifications of an existing freely available theme. No additional images are used, so rendering time should not be affected.
All tests were conducted 3 times, using a Test Round setting of 100. I picked the best score of the 3, as I was looking for best-case usage conditions. The results are ranked in order from fastest to slowest.
Engine: HighContrast
Theme: HighContrast
GtkEntry - time: 0.03
GtkComboBox - time: 0.63
GtkComboBoxEntry - time: 0.46
GtkSpinButton - time: 0.04
GtkProgressBar - time: 0.02
GtkToggleButton - time: 0.04
GtkCheckButton - time: 0.03
GtkRadioButton - time: 0.06
GtkTextView - Add text - time: 0.18
GtkTextView - Scroll - time: 0.08
GtkDrawingArea - Lines - time: 0.91
GtkDrawingArea - Circles - time: 1.21
GtkDrawingArea - Text - time: 0.89
GtkDrawingArea - Pixbufs - time: 0.11
---
Total time: 4.70
Engine: Rezlooks
Theme: Rezlooks Blue Ink*
GtkEntry - time: 0.05
GtkComboBox - time: 0.61
GtkComboBoxEntry - time: 0.41
GtkSpinButton - time: 0.05
GtkProgressBar - time: 0.03
GtkToggleButton - time: 0.06
GtkCheckButton - time: 0.04
GtkRadioButton - time: 0.11
GtkTextView - Add text - time: 0.18
GtkTextView - Scroll - time: 0.07
GtkDrawingArea - Lines - time: 0.94
GtkDrawingArea - Circles - time: 1.17
GtkDrawingArea - Text - time: 0.89
GtkDrawingArea - Pixbufs - time: 0.11
---
Total time: 4.72
Engine: Mist
Theme: Mist
GtkEntry - time: 0.03
GtkComboBox - time: 0.65
GtkComboBoxEntry - time: 0.45
GtkSpinButton - time: 0.06
GtkProgressBar - time: 0.03
GtkToggleButton - time: 0.05
GtkCheckButton - time: 0.04
GtkRadioButton - time: 0.10
GtkTextView - Add text - time: 0.18
GtkTextView - Scroll - time: 0.07
GtkDrawingArea - Lines - time: 0.87
GtkDrawingArea - Circles - time: 1.17
GtkDrawingArea - Text - time: 0.91
GtkDrawingArea - Pixbufs - time: 0.12
---
Total time: 4.72
Engine: ThinIce
Theme: ThinIce
GtkEntry - time: 0.03
GtkComboBox - time: 0.65
GtkComboBoxEntry - time: 0.42
GtkSpinButton - time: 0.07
GtkProgressBar - time: 0.03
GtkToggleButton - time: 0.05
GtkCheckButton - time: 0.03
GtkRadioButton - time: 0.07
GtkTextView - Add text - time: 0.19
GtkTextView - Scroll - time: 0.09
GtkDrawingArea - Lines - time: 0.91
GtkDrawingArea - Circles - time: 1.16
GtkDrawingArea - Text - time: 0.88
GtkDrawingArea - Pixbufs - time: 0.12
---
Total time: 4.72
Engine: Glide
Theme: Glider
GtkEntry - time: 0.06
GtkComboBox - time: 0.65
GtkComboBoxEntry - time: 0.49
GtkSpinButton - time: 0.08
GtkProgressBar - time: 0.03
GtkToggleButton - time: 0.05
GtkCheckButton - time: 0.05
GtkRadioButton - time: 0.14
GtkTextView - Add text - time: 0.20
GtkTextView - Scroll - time: 0.09
GtkDrawingArea - Lines - time: 0.85
GtkDrawingArea - Circles - time: 1.20
GtkDrawingArea - Text - time: 0.87
GtkDrawingArea - Pixbufs - time: 0.14
---
Total time: 4.90
Engine: Redmond95
Theme: Redmond
GtkEntry - time: 0.04
GtkComboBox - time: 0.76
GtkComboBoxEntry - time: 0.57
GtkSpinButton - time: 0.06
GtkProgressBar - time: 0.02
GtkToggleButton - time: 0.10
GtkCheckButton - time: 0.12
GtkRadioButton - time: 0.13
GtkTextView - Add text - time: 0.19
GtkTextView - Scroll - time: 0.08
GtkDrawingArea - Lines - time: 0.90
GtkDrawingArea - Circles - time: 1.17
GtkDrawingArea - Text - time: 0.90
GtkDrawingArea - Pixbufs - time: 0.12
---
Total time: 5.16
Engine: Clearlooks
Theme: Glossy
GtkEntry - time: 0.02
GtkComboBox - time: 0.77
GtkComboBoxEntry - time: 0.56
GtkSpinButton - time: 0.19
GtkProgressBar - time: 0.12
GtkToggleButton - time: 0.12
GtkCheckButton - time: 0.08
GtkRadioButton - time: 0.11
GtkTextView - Add text - time: 0.18
GtkTextView - Scroll - time: 0.10
GtkDrawingArea - Lines - time: 0.95
GtkDrawingArea - Circles - time: 1.17
GtkDrawingArea - Text - time: 0.91
GtkDrawingArea - Pixbufs - time: 0.12
---
Total time: 5.40
Engine: Crux
Theme: Crux
GtkEntry - time: 0.03
GtkComboBox - time: 0.89
GtkComboBoxEntry - time: 0.75
GtkSpinButton - time: 0.14
GtkProgressBar - time: 0.04
GtkToggleButton - time: 0.05
GtkCheckButton - time: 0.06
GtkRadioButton - time: 0.10
GtkTextView - Add text - time: 0.18
GtkTextView - Scroll - time: 0.12
GtkDrawingArea - Lines - time: 0.90
GtkDrawingArea - Circles - time: 1.16
GtkDrawingArea - Text - time: 0.90
GtkDrawingArea - Pixbufs - time: 0.13
---
Total time: 5.46
Engine: Industrial
Theme: Industrial
GtkEntry - time: 0.05
GtkComboBox - time: 1.13
GtkComboBoxEntry - time: 0.54
GtkSpinButton - time: 0.06
GtkProgressBar - time: 0.05
GtkToggleButton - time: 0.15
GtkCheckButton - time: 0.06
GtkRadioButton - time: 0.07
GtkTextView - Add text - time: 0.19
GtkTextView - Scroll - time: 0.15
GtkDrawingArea - Lines - time: 0.89
GtkDrawingArea - Circles - time: 1.16
GtkDrawingArea - Text - time: 0.91
GtkDrawingArea - Pixbufs - time: 0.12
---
Total time: 5.54
Engine: Aurora
Theme: Aurora
GtkEntry - time: 0.05
GtkComboBox - time: 1.10
GtkComboBoxEntry - time: 0.90
GtkSpinButton - time: 0.20
GtkProgressBar - time: 0.06
GtkToggleButton - time: 0.12
GtkCheckButton - time: 0.08
GtkRadioButton - time: 0.16
GtkTextView - Add text - time: 0.19
GtkTextView - Scroll - time: 0.13
GtkDrawingArea - Lines - time: 0.92
GtkDrawingArea - Circles - time: 1.17
GtkDrawingArea - Text - time: 0.89
GtkDrawingArea - Pixbufs - time: 0.12
---
Total time: 6.08
Engine: Pixmap
Theme: Elegant Autumn*
GtkEntry - time: 0.04
GtkComboBox - time: 1.00
GtkComboBoxEntry - time: 0.80
GtkSpinButton - time: 0.15
GtkProgressBar - time: 0.15
GtkToggleButton - time: 0.22
GtkCheckButton - time: 0.06
GtkRadioButton - time: 0.11
GtkTextView - Add text - time: 0.23
GtkTextView - Scroll - time: 0.23
GtkDrawingArea - Lines - time: 0.98
GtkDrawingArea - Circles - time: 1.17
GtkDrawingArea - Text - time: 0.92
GtkDrawingArea - Pixbufs - time: 0.13
---
Total time: 6.19
Engine: Candido
Theme: Graphite Light
GtkEntry - time: 0.05
GtkComboBox - time: 1.94
GtkComboBoxEntry - time: 1.36
GtkSpinButton - time: 0.08
GtkProgressBar - time: 0.17
GtkToggleButton - time: 0.22
GtkCheckButton - time: 0.07
GtkRadioButton - time: 0.09
GtkTextView - Add text - time: 0.22
GtkTextView - Scroll - time: 0.16
GtkDrawingArea - Lines - time: 0.89
GtkDrawingArea - Circles - time: 1.17
GtkDrawingArea - Text - time: 0.91
GtkDrawingArea - Pixbufs - time: 0.12
---
Total time: 7.45
Interesting. Six months (and one new graphics card and driver) later, there's been a bit of a shuffle. All engines tested are clustered much closer together. There used to be a 12-second gap between the fastest and slowest engines. Now it's only 3 seconds. Part of that disparity comes from new versions of the engines. Aurora in particular has made phenomenal improvements since 1.4; the numbers you see here are from version 1.5.1. It's no longer at the back of the pack -- last place now belongs to Candido, which is still rather slow, especially in the ComboBox tests.
Curiously, although the completion times are stacked very closely, there seemed to be a general slowdown. While the older gtk+ engines still turn in respectable times, they're not always at the front of the pack. In particular, the Pixmap engine, which has historically had a speedy reputation, is now trailing most other engines. The theme used is extremely simple. I'm not sure what's causing the slowdown here. Perhaps its reputation for speed is no longer deserved; even six months ago it wasn't a standout.
There's no longer an engine that can turn in 3-second completion times; in fact, the four fastest engines all tied at 4.7 seconds. Of the four, Rezlooks is without a doubt the prettiest. Many of the screenshots in my devspace feature Rezlooks themes.
Two of the engines added for this round of benchmarks, Crux and Redmond95, end up in the middle of the pack. They're not particularly fast, nor are they pleasing to the eye. The other two newcomers, ThinIce and HighContrast, distinguish themselves by jumping to the very top of the charts. HighContrast is undoubtedly the ugliest engine presented here, while ThinIce's appearance rather resembles Mist. It's tolerable, but nothing I'd use, personally.
Once again, I'll stick with Rezlooks-based themes, as well as the occasional standout Pixmap or Clearlooks theme such as ClearLUX. ClearLUX in particular is extremely easy on the eyes when doing late-night computer work.
But where are the Xfce engine results? Let's take a look . . .
The Xfce engine results baffled me. The completion times varied wildly, everywhere from middle-of-the-road to flat-out fast to back-of-the-pack. So I intermittently benchmarked the Xfce engine for an hour, under varying degrees of desktop activity. Everything from lots of different applications open to a completely blank desktop. I couldn't generate consistent results. So, I decided to close down all applications and run a final series of three tests. Presented here are the slowest and fastest times logged for this series.
Engine: Xfce
Theme: Xfce
Slowest times
GtkEntry - time: 0.06
GtkComboBox - time: 1.18
GtkComboBoxEntry - time: 0.50
GtkSpinButton - time: 0.08
GtkProgressBar - time: 0.07
GtkToggleButton - time: 0.08
GtkCheckButton - time: 0.03
GtkRadioButton - time: 0.06
GtkTextView - Add text - time: 0.20
GtkTextView - Scroll - time: 0.14
GtkDrawingArea - Lines - time: 0.90
GtkDrawingArea - Circles - time: 1.17
GtkDrawingArea - Text - time: 0.94
GtkDrawingArea - Pixbufs - time: 0.15
---
Total time: 5.56
Fastest times
GtkEntry - time: 0.02
GtkComboBox - time: 0.55
GtkComboBoxEntry - time: 0.43
GtkSpinButton - time: 0.06
GtkProgressBar - time: 0.06
GtkToggleButton - time: 0.06
GtkCheckButton - time: 0.03
GtkRadioButton - time: 0.04
GtkTextView - Add text - time: 0.18
GtkTextView - Scroll - time: 0.12
GtkDrawingArea - Lines - time: 0.86
GtkDrawingArea - Circles - time: 1.19
GtkDrawingArea - Text - time: 0.90
GtkDrawingArea - Pixbufs - time: 0.12
---
Total time: 4.63
Look at that. A completion time of 4.63 seconds, well ahead of any other engine. That's best-case though; it can be almost as slow as the Aurora engine, which is notoriously heavy. The DrawingArea and TextView numbers are fairly static in both sets. Everything else tends to vary widely. No idea why. Perhaps the developers have made some changes under the hood between Xfce 4.4 and 4.6?
Recently in Xfce
This is just a short post with what happened recently in Xfce.
- Xfce4 Power Manager 0.8.0 was released. I did not have time yet to test it, but it looks promising.
- Jannis Pohlmann and Stephan Arts drafted a release process for Xfce. It still needs to be discussed, but it already looks great. Expect some progress on this once the migration to git is done.
- Brian Tarricone worked a lot on the git migration, things are almost settled.
- Jannis Pohlmann is making some awesome progress on Thunar. He developped Tumbler, a D-Bus thumbnailing service based on the thumbnail management D-Bus specification, to replace the old thumbnailing code. A video shows how his first experimental implementation behaves.
- Nick Schermer made a lot of progress on Xfce4 Panel, fixing and lot of bugs and improving performances. His code can be found on git.xfce.org.
- Stephan Arts has improved the git version of Ristretto a lot: it works, supports basic printing and features a new improved user interface.
- It seems that Colin Leroy will be the maintainer of Xfce4 Weather Plugin from now on. Welcome!
- Mike Massonnet rewrote Xfce4 Notes Plugin in Vala, and improved and lot of things at the same time. Expect a release soon.
- Ali Abdallah, the developper of Xfce4 Power Manager, added a new Goodie to the SVN. Parole is a Gstreamer based media player. I did not test it, so I cannot say more...
News Update
A lot of things are going on lately and it turns out I'm way to busy to update my weblog on a regular basis. So, this is just a short post to keep you all updated.
Last two weeks
- I took a new student job at the university, at the Institute of Theoretical Computer Science, which I love most. I'll be working on haplotyping algorithms.
- I went to Barcelona and had a great time at the Ubuntu Developer Summit overall. Stephan and I were very productive. One evening during dinner we discussed our development and release process and later started writing it down. The result is a beautiful document that still needs a bit of polishing. I hope it'll serve as a good foundation for the development and release process of Xfce in the future. Several others commented on it and it looks like we'll give the proposed concept a shot after we've switched to git and all that.
- Even though the week in Barcelona was great for Xfce, I was disappointed with how it went with regards to the cooperation between Xubuntu and Xfce. I talked it through with Stephan and after I got back, I resigned from my position as the Xubuntu Xfce4 Liaison.
At the moment
- I've started to implement the so-called thumbnail management D-Bus specification. My implementation is called Tumbler and it will hopefully start serving thumbnails for other apps soon. I'm planning to use it in Thunar, Stephan has expressed interest in using it in Ristretto and when discussing the specification and the existing hildon-thumbnail implementation, Philip van Hoof told me that Hildon/Nokia might be interested in dropping hildon-thumbnail in favor of Tumbler if it's flexible enough. I'm working on it as much as I can and I'm hoping to do a release within the next few weeks.
- I'm still working on the Transifex installation for Xfce. It's already running but I still need to import all the projects, releases and of course create accounts for maintainers automatically.
- The migration of Xfce to Git is still work in progress. Brian has most of the repository issues sorted out and is now waiting for me to finish the commit mail script. I have two or three possible implementations lying around but I need to have a look at that again.
- Jim needs the documentation repository next week, so I'm about to set it up.
- Our Buildbot server has arrived in Sweden. Today I set up the firewall. Samual is taking care of setting up the Buildbot host VM and other things. We're considering to move a lot of the services not related to development (like the Xfce websites) into separate VMs on that server too, in order to make the current server a development-only machine.
Besides that I'm trying to catch up with the work and personal stuff that piled up while I was away last week. And I really should go and sleep.