Mono @ PDC 2008

For those who weren't able to attend Microsoft's Professional Developer's Conference this past week, Miguel gave a presentation (wmv) about Mono detailing some exciting new developments.

For example, Mono 2.2 (slated for the first week of December) will have a C# shell which Miguel and Marek have been working on and which Microsoft has announced will be part of C# version 5, slated for release sometime in 2012 (yes, that means Mono is ahead of Microsoft!).

Also presented was Mono in video games, such as those on the Wii and iPhone platforms (which are both supported targets of the Unity3D game development studio). Some game studios are apparently also using Mono on the PlayStation3, Xbox360, Windows, and Mac platforms. The main interest here was that Unity3D has been rewritten from Objective-C (on the Mac platform) to C# which should make it eventually portable to Linux (C# version now runs on Windows and Mac).

Another interesting development that came about because of interest in using Mono for video games (since some game development studios are now writing games in fully managed code), was that it was important for Mono to get SIMD support which has now been implemented and will be available in Mono 2.2. This has made Mono extremely fast (up to 10x faster) with respect to 3D vector math and other areas that benefit from SIMD.

This is really exciting!

Optimizing Moonlight's InkPresenter

This past week I started out staring at endless amounts of javascript trying to figure out what it was supposed to do so that I could figure out what Moonlight was breaking on in order to fix some bugs. As you can imagine, this is a slow and boring process where one's eyes go dry and it feels like you are getting nowhere fast.

As occasionally happens, I give up and move onto the next bug hoping that the next bug will be easier to fix and/or give me some insight into the previous bug. As it turned out, I moved onto bug #409793 which was a performance bug on sites like Ink Journal and Ink Tattoo Studio.

What was happening on these sites was that as more points got added to the stroke, rendering would get slower and slower (thus causing the line to lag behind the mouse cursor) because Moonlight was invalidating the entire InkPresenter canvas on each frame and so having to render the entire thing even though it was unnecessary.

To optimize this, I added a 'dirty' rectangle that kept track of the actual regions we needed to redraw. As points got added to the collection between frames, I added the bounds of the new point plus the region between the new point and the previous/next points (the 'next' point is obviously only needed if the newly added point was an insertion). The result for sites like InkJournal and InkTattooStudio was that we only invalidated the newly appended points at each frame render, vastly improving our performance which now matches Microsoft's Silverlight performance for these sites afaict.

Re: It's Time for a FOSS Community Code of Conduct

Bruce Byfield's article, It's Time for a FOSS Community Code of Conduct, has sadly made me aware that this particular problem is more widespread than I thought.

To Aaron Saigo & the rest of the KDE team: just keep rocking, dudes. Eventually these donkeys will either give up or be committed to mental institutions (or better yet, they'll cross paths with someone just like them and get what's coming around).

To the people out there attacking developers/projects:

Like I blogged a few years ago, rampant fanboyism is fine so long as you can keep it positive. You aren't doing the project you support any favors when you badmouth the other projects.

For example, GNOME devs aren't pleased when they see GNOME fanboys attack KDE all over forums or on news sites.

I'm sure the KDE devs feel the same way.

QuakeLight: A Silverlight Port of Quake

Looks like Channel9 has just put up a video screen cast of QuakeLight, the Silverlight port of Quake - probably the game I lost the most amount of productivity to back in the late 90's.

I'd love to play with this under Moonlight to see how well we fare...

Update: Here's a handy link to an interview with the developer.

Parallel-Installable Gtk-Docs

I recently release GMime 2.4.0 but missed the fact that the gtk-docs would install into the same location as the old 2.2 docs, namely ${prefix}/share/gtk-doc/html/gmime. Thwe problem is clear, since GMime 2.4 changed API (rather than just extending the 2.0/2.2 API), GMime 2.4 really needs to be fully parallel installable.

Thanks to Gilles Dartiguelongue from the Gentoo community for discovering this and bringing it to my attention.

As I tried to figure out how to accomplish what I needed, I discovered that Gtk-Doc needed some fixes so I did a quick hack and submitted it upstream.

Unfortunately, my original fix was broken in that I didn't realize that a simple version extension to the install directory wouldn't be enough because GNOME's devhelp program expected the .devhelp and .devhelp2 files would be named with the same version extension, or they would not be detected.

After that was pointed out to me, I looked deeper into the problem and discovered it wasn't such a terribly hard fix afterall, just a little shell scripting magic was all that was needed ;-)

Since Stefan Kost (the gtk-doc maintainer) and myself were both interested in such a solution, I figured there must be other library maintainers who would be interested in this and so thought I would blog about it.

For those interested in packaging GMime 2.4.x for the various distros, I'll be releasing a 2.4.2 release in the next day or so (going to wait a little longer just in case anyone finds any other last minute parallel-install bugs in the gmime-2.4.1.1 tarball I put together for testing; it's bad enough that I've already released a gmime-2.4.1 with nothing but parallel install fixes and that 2.4.2 will be more of the same, I'd rather not have to issue a 2.4.3).

Setting Up a Multi-Tabbed GNOME-Terminal Development Environment

For many developers (such as myself), the first thing we tend to do when we login to our desktops, is to launch gnome-terminal (or similar) with a number of tabs and then will typically have to setup a bunch of environment variables in each tab.

Most of us have probably simplified this at least somewhat by creating a file that sets our environment variables for us when we do

. ~/project.env

or something to that effect.

The problem is that if we have multiple tabs that we've got to source our project.env files in, this gets tedious.

This morning, Rolf shared with me a way to spawn gnome-terminal and have it automatically cd into a list of specified working-directories... but I wanted to take it a step further and have gnome-terminal auto-magically source my project environment variables.

Here's how I solved this problem:

* Step 1: Create a ~/bin/devterms shell script:

#!/bin/bash -e

MONO_ENV="/bin/bash --rcfile ~/.devtermsrc -i"

gnome-terminal \
  --tab --working-directory=/cvs/moon --command="$MONO_ENV" \
  --tab --working-directory=/cvs/moon/test --command="$MONO_ENV" \
  --tab --working-directory=/cvs/mono --command="$MONO_ENV" \
  --tab --working-directory=/cvs/monodevelop --command="$MONO_ENV" \
  &

* Step 2: Create ~/.devtermsrc rc file for bash:

# Load ~/.bashrc to setup all of my standard environment variables and aliases
test -s ~/.bashrc && . ~/.bashrc || true

# Load Mono-specific development environment variables
test -s ~/mono.env && . ~/mono.env || true

* Step 3: Create a launcher (in my case, I made ~/Desktop/Development Environment.desktop):

[Desktop Entry]
Encoding=UTF-8
Version=1.0
Type=Application
Terminal=false
Name[en_US]=Development Environment
Exec=/home/fejj/bin/devterms
Name=Development Environment
Icon=gnome-terminal

Hopefully this will help other people make their own lives a little simpler.