Entries Tagged 'General' ↓

I had a very relaxing holiday. 3 weeks in Italy. And since I’m a geek (or a nerd, up to you), I took all Flash games from OneMoreLevel.com with me. The result is a huge amount of bugfixes and speedups in Swfdec for supporting the best of those games. I was really happy to see how many of those games already work in Swfdec. So I guess Swfdec is no longer just a Youtube player, but can do all those time-wasting games, too.

And today I wrapped all of that into a Swfdec 0.5.3 release, so you can have fun playing games, too. I’ve updated the Screenshots page with screenshots of and links to those games, so you can play them yourself now.
And to save you one click, the most awesome game definitely is Tennis. I’ve spent days trying to make Anna Kournikova (the worst player) defeat Steffi Graf (the best one):

Thomas, I think this method might even be faster than using Python. And it’s even faster if you have a local checkout of the sources handy. And I think every developer should have checkouts of all the libraries he uses to look at for answering questions.

Let me introduce you to Jeff (photo kindly provided by Google Images). Jeff is an incredibly smart guy. He solves really all the really hard problems with very little code. These days he works for Microsoft as that’s where the hard problems are today. But back in the days he worked on Flash. And that was when Flash had the problem that startup was slow for large files. So Jeff came up with the smart solution to just limit the initial read to 64kB, or 65536 bytes. So files that are 64kB or smaller will be completely parsed when the first frame executes, larger files aren’t.

Does that matter? Yes, because there’s Flash files that assume that they’re not loaded completely in frame 1 and otherwise hang in an infinite loop (I’m debugging such a file right now). So it’s actually quite important to get right. But I don’t think any standard states this as required behavior. So much for usefulness of standards.

Alex has a post about laziness of developers. At least that’s the part I wanna focus on. He is wondering why people used to be ok with fixing the build but now they are “are unwilling to try out new things”.

I think it’s not the developer seniority he points out that’s the problem. At least it’s not the only problem. There is two more points. The first is the size of the project. People used to understand how all the software on their machine worked and what it did. I used to build an LFS and had looked at all the files in /etc. These days ai Can’t even get on the net anymore if NetworkManager doesn’t do it. And that’s not because I became stupid. It’s because I’d need to know the wireless extensions, wpa, hotplug and hal, and not just the right ifconfig line.
The second issue is the general quality of the software. People remembering the time of October Gnome know that problem: applications used to crash or not build. Fixing that was mostly easy. (This had the side effect of a low barrier of entry that helped attract lots of people, but that’s another story.) Today software is expected to be translated, crash-free and easy to build. Various distros are annoyed at libswfdec not having a stable API. 5 years ago people would have laughed at that requirement. So because all the other software today is better, people expect new software to be better, too. You can’t impress people with DOS games anymore.

The approach I’m trying to take in this laziness problem with Swfdec is pretty easy, and is probably the same as for all software in development, but it should be spelled out. I think some people might not have realized this, both people interested in helping or just random people commenting on your software. Here it goes: The most important people are the people working on the project. If the developers have to jump over too many hurdles, they’ll not get stuff done and that is most important at this stage of the project. So if the developers want to use git, the software will be hosted in git. The second most important people are testers and packagers, i.e. all the people that directly work with the source code. The normal user running the application comes last. This is for quite simple reasons: There’s more testers than users – or at least almost as many – and they are a lot more important for the project. They find loads of bugs, report them and help in fixing them. This order of priorities can be seen in the current features of Swfdec: There is an internal debugger, but no stand-alone player. There is the possibility to download movies in the plugin (You need the files to debug them), but it doesn’t do any sort of preferences.

When the project grows up and the number of users increases, this will gradually shift. You can see this with mature software such as Gnome: Not surprising the user is a way more important thing for new releases than adding cool new features. You can of course also notice that such user-friendly software advances way slower than unstable software where developers can change everything to their heart’s content. Both kinds of developments have their place. And the cool thing about it from the users’ point of view is that they can influence the state of a project: The more people use it, the more user-oriented it will become.

I released Swfdec 0.5.2 today. This was an answer to the Ubuntu team that asked to have a new release to go with the Gutsy freeze. Diffstats showed 3k adds in libswfdec/ and 12k adds in total – for 3 weeks, that is pretty awesome. It even makes me the 6th most active C Free software coder!

This release also marks an important point, because it makes the Flash file work that David always wanted to have working. So we fullfilled the goal that made the project founder give up. ;) And while doing all this and walking down history lane, I realized I never thanked the people that make Swfdec go at the pace it currently does. So here is a (most likely incomplete) list of Thank you’s:

• David for starting Swfdec and writing such a sane file parser and jpeg library. I love not having sigsetjmp() in my code.
• Eric for being a great reference on all things X and BSD and doing the admin tasks on Freedesktop.
• Pekka, who suddenly showed up and started testing and fixing all this stuff I’ve always been too lazy to do. Sorry Warsow guys. :p
• Klaus and Sandro for hacking on Ming, that makes writing tests bearable and easy.
• Carl for enduring my questions and helping me slowly get rid of my ignorance of all things graphics. Oh, and he also manages Cairo.
• Andreas, PClouds (his actual name is Nguyễn Thái Ngọc Duy, but I can’t pronounce it, so I always think of him as PClouds) and all the other people that submitted patches.
• Michael, Mario, Alexander and all the other packagers that ensure the code I write works and works well.
• Johan and the rest of the Gtk team for Gtk, and in particular GtkBuilder. Building GUIs made easy again.
• Ryan for dvalue. And for knowing all this stuff about C.
• Richard for that one email back in the days. I wonder if he even remembers it.
• And last but not least Ulrike and the rest of my family, who live with me ignoring them for hours or (probably worse) showing them stupid Flash files that work.

So, how many people work on Swfdec?

And Swfdec’s day, too. First I merged the new debugger into master without any issues. So now everyone hacking on Swfdec can profit from Vivified greatness.

After doing so, I used it. And made bloxorz.swf go from this:
to this:

And if that wasn’t enough, I made Kittencannon work. Here’s the 23MB proof in slow motion. And to top it all off, Pekka has finished making variable flags work. 4 awesome things in one day.

Both of those bugs were longstanding bugs where I had no idea what was causing them. It’s one of the things I have been thinking about a lot. Swfdec is a virtual machine that runs for a long time and at some point you notice something is wrong. But how do you figure out which of the thousands or millions of executed statements caused it? So far the only solution I had was using my knowledge of the codebase and printf debugging, which is not really that great. gdb is not really helpful for stuff that runs for long times, as it always interrupts and it’s hard to inspect the running program.
Vivified so far is only two things: 1) an improved way to insert printfs – by inserting prints in the debugger’s hooks and 2) a UI for common things to look at, so printf isn’t needed. Vivified keeps a tree of the currently running movieclip instances, so it’s easy to see when one goes away when it shouldn’t, even an invisible one. It helps tremendously (see above), but I have the feeling it can be done way better.

When looking at other software with the same problems in Gnome land, there isn’t really a lot. Most Gtk applications aren’t long-running, they’re mostly short snippets of code after a user action. The parts that are (session startup) pretty much use the same approach that GStreamer uses, and that approach is the old one: printf. GStreamer just has this glorified printf framework where one has to look through 3GB of output to find a bug, which is neither easy nor intuitive. So I guess I should end this rambling with a “dear interweb”: Dear Interweb, do you know of ways to debug long running applications and find bugs that happened 20 minutes ago but only caused a problem now?

Watch this!

Your only excuse of not watching it is if you already use git. It’s a one-hour Google tech talk from Linus about Git. You not only learn why Git is the only sane RCS to use, but also that Subversion designers are stupid and that Linus doesn’t trust Google. He claims to not even trust Andrew Morton to take his medicine every day.

Quite some people have asked what the vivi branch in swfdec git is supposed to be. It’s my rewrite of the debugger. I’m actually pretty proud of how nice it turns out. I’ve taken the Flash virtual machine that Swfdec contains anyway and hooked it up with libming Flash compiler. The result is a Flash debugger written in Flash. The first screenshot of some things possible with it is here (click image for unscaled view):

The right tools are pretty much the most important thing when reverse engineering. How else am I to find what Swfdec does wrong if I’m not able to watch closely what it does at all times? Until the first video image is visible of a Youtube video, Swfdec has called 4500 functions and executed 70000 bytecodes (aren’t scriptable debuggers fun?). And if it does one bytecode or function call wrong, I have to find that. 75000 places to look. Fun!

In related news, Ubuntu seems to have almost managed to package Swfdec – finally. So you can stop poking me about packages.

Anyway, I’ll go back writing some more scripts in the debugger. Gathering stupid statistics is awesome. Especially when doing it with software I’m proud of.

I’ve just been reading about the new Java popup exploit. It’s one of the “too much space” problems: applications are given the ability to acquire more screen space than is assigned to them. And it’s not only a problem with screen space – it’s certainly most visible there – but it’s also important for keyboard focus stealing.

It’s not only a problem for browsers, it’s a problem with lots of other technologies. I bet the window manager hackers know this: What do you do when a new window pops up (and grabs focus) while I am working in a different window? What does a filled panel do if the notification area or the drivemount applet suddenly get new icons? What do you think about applicatrions that decide to resize their windows without you requesting it? Or notifications that are always in the way? Popup blocking common in browsers tries to address this problem, but the alert() Javascript function can still escape its assigned space and keyboard focus.

Adobe’s Flash has been pretty good in respecting its assigned size. If you want to resize a Flash application, your only choice is calling back into the website to make it enlarge the embed window. Flash itself cannot resize. Or better: could not. It recently acquired the Stage.displayState property that allows it to go fullscreen. It seems to have been added primarily so you can watch your Youtube videos fullscreen (Youtube supports it already). Like popup blocking, it only works on mouse clicks, not all the time. I’ve been wondering how to implement it nicely in Swfdec, since I think the implementation in Adobe’s player leaves something to be desired: The annoying “Hi, I’m a popup, press Escape to close me” bar that shows in the middle for a short while after fullscreening. And I wonder if disabling keyboard input is a good idea.

Back to the original topic: If you’re a developer that writes an application that runs embedded scripts/applications, please do me a favour and don’t let them decide on resizing and focus stealing. And if you write an application that does this, please spend some time thinking about how to handle this.

I’d like to close with a very special cheers to Vincent and the people discussing embedding the notification area into the panel by default.

It’s fun to finally run around in feature-land again. Stuff I do has an effect on real Flash files again and doesn’t just make more of my crazy tests work. Still, I remember it being more fun when the code and testsuite were smaller and I didn’t break stuff all the time. ;)

Anyway, Swfdec properly plays embedded Youtube now. Here’s the proof:

And to make you enjoy it, I’ve done a 0.5.1 release of Swfdec. Have fun!