Entries Tagged 'General' ↓

So my cute little iBook decided to die last week. Since the conference season is about to come in full swing, I needed a laptop, and I needed it now. Long story short: no one in the 12″ 1000 Euro segment comes even close to Apple. I really looked, because I’m only a fan of hot pants when I don’t have them. (Yes, that was a bad pun on the Macbook getting hot.) But even the Toshiba U200 is not a real contender. Anyway, I installed Ubuntu Gutsy on my shiny new 2nd generation Macbook in the hope it’d just work and here’s the good, the bad and the ugly about it:

The good
All hardware is supported and supported pretty well. Everything has a featureful driver. There’s also a lot of people caring about this machine. I can find blog or forum posts about almost every issue. Try to find out anything about that Toshiba machine and you’re lost. A big thank you for the work done by the Ubuntu laptop testing team in helping me decide and know potential problems in advance.

The bad
This is the stuff I managed to fix that didn’t work out of the box. First thing of note is the driver for the Intel graphic card. Compiz refuses to work (I blame Gutsy) and it still needs the 915resolution utility to correctly identify the correct resolution. This somehow shattered my dream of flawless Intel drivers. ;) And the Ubuntu installation doesn’t install the DRI GL libraries. Shouldn’t that be done by default? The second thing that didn’t work out of the box was wireless. I had to build a current Madwifi snapshot to make it work. But after doing so, it haven’t had any issues. The third issue is the touchpad. The Apple touchpad is one of the best inventions since sliced bread. Unfortunately, I only knew that because I used in in OS X for 20 minutes. The default configuration on X is bad, since it disables all the awesome features. Fortunately, there’s the synclient tool to reenable them. The driver could also need some tweaks here and there (in particular for detecting scrolling). But after that, multi-finger operations are just too good to not get used to immediately.

The ugly
This is the stuff I couldn’t make work. Luckily it’s all software issues, so I have hopes. Number one: Suspend doesn’t work. Boy, is a notebook without suspend useless. Especially because startup still takes ages (go blizzard, go hughsie!). It just doesn’t resume anymore. And hibernate doesn’t work either. It just shows a blinking cursor forever. The brightness controls don’t work either and I was too lazy to install desrt’s hack. I’d prefer to have it fixed properly. And last but not least, the volume controls for the sound card get totally mixed up. This seems to be a problem with the drivers, since even alsamixer labels the sliders wrong.

Short summary: Ubuntu on a Macbook is still an experience and quite a bit away from “just works”. Looks like I need to play “find the sweet kernel” with it for a while. Other than that, it’s awesome.

Update: Since 2 minutes and a dist-upgrade ago, sleep works. I guess the Ubuntu hackers want to reinforce my last point.

Dear interweb, I was gonna share a room with Mathias Hasselmann at the Etap hotel for Guadec. However, I’m gonna stay from 14th to 22nd and he’s gonna leave at the 19th already, which leaves us 3 days with a room that’s half-empty. Do you know people that have a similar problem, so we could get rid of two half-empty rooms? If so, please mail me or contact me on IRC.

Since quite some people have asked how to do tests for Swfdec, here’s a short Howto. You need:

• Ming for creating the test files. You probably want a 0.4.0 beta, and not the packages found in distros.

A Flash debug player. I use the Windows debug player via wine.

You need to configure the debug player to provide debug output. Create the file ~/.wine/dosdevices/c:/windows/profiles/$USERNAME/mm.cfg and have its contents be (you might need Windows-style CRLF line feeds, not sure):

ErrorReportingEnable=1
TraceOutputFileEnable=1

Now for every Flash file you run with the debug player, a text file will be created that contains trace output and other interesting warnings. It will be at
~/.wine/dosdevices/c:/windows/profiles/$USERNAME/Application Data/Macromedia/Flash Player/Logs/flashlog.txt. I have softlinked that file to flash.log.

Now we need to write a test. Have a look at the test/trace/ subdirectory and the included *.as and *.c files to learn about those tests. The directory also contains a README file, that might give some hints. I’ll focus on the as files here. So let’s assume, we really want to know if NaN == NaN, we’ll write a small test file nan.as:

// makeswf -v 7 -s 200x150 -r 1 -o nan.swf nan.as

// Add a nice description here, so we have an idea what this test is about when it fails.
trace ("Check if NaN == NaN");
trace (NaN == NaN);

// This quits Adobe's Flash player, so we don't have to close it automatically.
loadMovie ("FSCommand:quit", "");

Now compile and run it:

makeswf -v 7 -s 200x150 -r 1 -o nan.swf nan.as && \
wine sa_flashplayer_9_debug.exe nan.swf && \
cp flash.log nan.swf.trace && \
perl -pi -e 's/\\r\\n$/\\n/;' nan.swf.trace;

As you can see, the debug output was copied to the right filename and line feeds were adapted already. Now just copy the files into Swfdec’s test/trace directory and see if Swfdec handles it correctly by running ./trace nan.swf. If it doesn’t, it’ll print the diff between the trace file and the output of Swfdec. And you can go looking at the code to determine who’s at fault. Or write the next test. :)

Dear Google, why do you think I’m too stupid to watch movies and need a GoogleVideoPlayer.exe? You seem to be able to hand me the file just fine when running on Linux.

Or have you guys recently realized that Linux users are smarter?

Lots of people keep asking this, so here is the authoritative answer to the question “What’s been happening to Swfdec in the last months?”

The bad news is that there haven’t been many new features. At least nothing that would be very visible. The good news is that this is about to change soon. I’ve been spending most of my time understanding the inner workings of Flash’s script engine and reimplementing it in a brand-new script engine for Swfdec. I’ve thrown away about 70% of the glue code to make objects scriptable. Making scriptable objects is now extremely easy. This should speed up coding immensely, both for me and for new contributors.

The biggest issue so far when making Flash files work has been finding subtle bugs. Swfdec is very good at complaining about missing features to stderr (see my last blog), but other things are more subtle. For example: is NaN == NaN? Sure, if you tested it, you know the answer, but if you just coded it, you’ll probably get it wrong. And finding such a problem inside huge 16.000 lines of code (that’s the size of the Google Video Flash plugin) is very hard. So I’ve been looking for ways to find these issues earlier. I hope it works out.

I’ve also developed a habit of writing a test when I’m not sure about a feature, which has helped a great deal. The testsuite has increased from 90 tests to almost 200 tests and there’s another 150-200 tests lying around waiting to be cleaned up and committed.

So, in short, for the user, nothing new to show. For developers, lots of exciting new stuff has landed. If you are a developer, today is a good day to start. Grab the code, head into #swfdec and start hacking. The hard work behind the scenes is done, now it’s time for features.

So someone recently asked me how to hack on Swfdec. And since that might be interesting to others, I thought I’d blog about it. One thing to note: All the action these days is in the “as” branch, which will become Swfdec 0.5 in the near future.

So the first thing I do is download the file I want to make work. Surprisingly, the Swfdec Mozilla plugin allows downloading Flash files from its properties dialog, which you can get to by right-clicking on the playing file.

Now I play the file with the little application (in Swfdec’s git checkout) player/swfplay inside a terminal. It will spew out debugging information. A lot of this debugging information will be about missing features. So I start at the top and implement all those missing features, most of the time by writing accompanying tests. (How to easily write good tests is a post as big as this, so I’ll leave that out for now. Poke me to write it if you care.)

Here’s a few of the more common messages and what to do about it:

SWFDEC: ERROR: swfdec_script.c(198): validate_action: no function for  36 0x24 CloneSprite in v6

This means a bytecode isn’t implemented yet. The bytecode interpreter is in libswfdec/swfdec_as_interpret.c – just add the function there that does the right thing.

SWFDEC: ERROR: swfdec_as_interpret.c(678): swfdec_action_call_method: no function named createEmptyMovieClip

An Actionscript function isn’t implemented. First I figure out what object it belongs to and what it does by looking at Brajeshwar’s excellent Actionscript reference. Then I implement it. Note that a lot of function have really weird effects if called with unexpected parameters. So it really helps to write tests here.

SWFDEC: WARN : swfdec_as_interpret.c(1316): swfdec_action_new_object: Sound is not a constructor

It looks like an object isn’t implemented at all. So I do the same thing as above. I implement it, then run player/swfplay to see which functions on the object are used and implement those.

If I managed to implement all the functions that needed to be implemented and it still doesn’t work, then the hard work starts. That’s where I launch player/swfdebug and step through the code looking if what it does is sane. Swfdebug is a nice little tools for debugging Flash files that unfortunately is a little crashy and accumulates features as I need them. There’s also some tools in the test/ directory that help understanding particular Flash files, in particular test/dump that dumps information about the static content of a file (run with -v for maximum output) or test/swfdec-extract that can extract contents of Flash files to png or svg and I think it even extracts audio these days.

And when I’m finally done doing all this, I have one more file to play with. And most of the time I also know 3 more places that need serious refactoring…

So, if you now want to hack on Swfdec, a good idea is to come to IRC on Freenode, channel #swfdec and start asking questions. If you don’t want to use IRC, you can also mail the mailing list, just reading commit messages there is boring anyway.

Zack has a long blog about browser plugins. And he advocates going the XEmbed route. Originally I wrote this as a comment, but I think more people should know about the mess that is called browser plugins.

Swfdec used to be an out-of-process plugin. That plugin had all the nice features he mentions, but utterly fails for other things:

• translucency. If you use an X window for embedding as in XEmbed, you suddenly need Composite support to be able to do it.
• z-order. It’s absolutely fine to pop up a DIV on top of any plugin. If you go the X-Window route, you’re in for quite a ride since suddenly you have to create an X-Window for (at least) every DIV.
• Input events. You know when you use the mouse wheel on top of an embedded Flash animation and it doesn’t scroll? Or when you press Ctrl-T to open a new tab and none opens because the plugin has keyboard focus? Those.

So how would I solve the current mess? I would go the same route every other application with plugins goes. I’d write one plugin for every application. There’s really no need to have shared plugins. Noone wants to run Rhythmbox plugins in Amarok or Konq plugins in Nautilus.
If every browser had its own plugin system, suddenly Swfdec could use all the nice APIs of the browser. It could integrate its properties with the Konq properties dialog. It could share common properties (“run animations [x] always [ ] once [ ] never”, “sound [ ] enabled [x] disabled”), it could react to events (like ESC stopping animations). And there’ll probably be lots more I’m missing.

I can imagine two reasons why browsers didn’t go that route. The first is closed source plugins. Adobe ships Flash only for Moz plugins. So everyone tries to add support for that one plugin. And the second reason is that there really isn’t a huge demand for plugins. There’s really only Flash and Video players. Integrate those two natively and you don’t even need plugin support at all.

Oh, and one final note. Please stop bringing up the “misbehaving plugins” argument. It’s the reason for so much braindead code trying to cope with “misbehaving” stuff. If some code is broken, fix the broken code, don’t try to work around it. It feels like advocating to render every tab out-of-process, because then one page crashing doesn’t kill the browser…

Everybody knows about multiple solutions to the same problem. Everybody and their mom complains about them and that they should merge or at least work together. Surprisingly they do. At least most of the time. And of course there’s an exception. It’s called distributions. Noone complains about the fact that there’s a huge amount of them. And noone complains about the fact that they don’t work together. And I’m experiencing this on two different fronts now.

Imagine a project where upstream is in some “broken” state. Examples include, but are probably not limited to FFmpeg not doing releases and Mozilla not being able to ship one development platform. So what do the distros do to solve that problem? Right, they get creative. FFmpeg version numbers range from 0.49 to 0d.51. I bet you can guess which one is more recent. Now sometimes upstream gets in a good mood and tries to fix it. (I’ve heard that m4 macro is not always working. ;))

Dear distros, could you make life of us hackers simpler, and when you encounter a broken upstream, get together and work out a solution that makes life easy for us? It would make life a lot easier for us developers of not-broken packages and people that compile from sources like jhbuild.

Dear everyone else, in case you encounter a package that I maintain and that package doesn’t build on your distro of choice, there’s a pretty good chance of a broken upstream and distros being creative. I’ll most likely have a rant in configure.ac in that case. And then: Blame your distro.

PS: Thanks to Olav Vitters my blog moved from Advogato to GNOME blogs. So you can write comments now.

If anyone is interested and able to speak German there’s an
interview about
Swfdec I recently did. I think it turned out quite nice.

<ds> dude. zzuf rocks

Anybody coding an app that has to handle untrusted
input should have used zzuf. A lot.