Cool new stuff

Sun compiled two very interesting articles about New and updated desktop features in JDK6 (part1 and part2). Very interesting reading and quite exciting that Swing and Java2D finally receive more polish with respect to better desktop integration. I’m quite a fan of Swing (naturally), but in the past it has been annoying that Swing applications never seemed to really fit into the desktop. This is greatly improved in JDK6.

The GTK L&F needs more love though. It looks much better than in JDK5, but there are still many remaining issues. It still looks like a mix of GTK and Metal. For example the toolbars are clearly metal-ish, as is the file chooser. Tabs are something completely different, but definitely not GTK. Then there are lots of 1 pixel errors and a general feeling of slowness. I do however understand the difficulty in implementing such a L&F. GTK still does not provide any kind of API, at least not documented, to access the theme engine ‘from the outside’, e.g. from Swing. That is one of the biggest obstacles why I never got around to start such a L&F for GNU Classpath (besides the general lack of time).

On a different note, today I finished off (well sortof), the WindML BufferedImage/VolatileImage overhaul in the JamaicaVM. It now supports RGB565 and ARGB1555 images accelerated (for VolatileImage possibly even in the Video RAM when the driver supports this, grmbl) and ARGB8888 at least natively buffered, thus minimizing the overhead of getting the image on the screen. That’s pretty much as good as it can get on that platform. That makes up for a pretty nice performance improvement, as well as a much better memory handling (not speaking of the cleanup effect…). Many thanks go to Dmitri Trembovetski for patiently answering questions and cleaning up some misconceptions of mine!

On an even different note, my cat is going crazy for some days now. I wonder if she has hormone problems with the spring coming up here. 😉 Strange to see all those spring flowers bloom already in the mid of february though.


Windows sucks

This is going to be a pseudo rant. So read on or not…
Read more of this post

Netbeans vs Eclipse

The last couple of days I have desparately tried to use NetBeans for some of my work instead of Eclipse. Read on for a skimmy comparison (or rather, a list of issues that I found with NetBeans)…
Read more of this post

What a week

Phew. That was the last exam today. Never ever will I sit in that room and write an exam again :-). I still can’t believe that this chapter is finally coming to an end. This means that I am now going full steam to finish the diploma thesis and then I’m FREE! Right now I feel quite exhausted though, I think I’ll take a weekend off to get some energy…

Fuck your Brain

My time at university is coming to an end. This means that my accounts there will be deleted anytime soon. At the very beginning of my study me and a friend have put together some webpages (in german) dedicated to the wonderful programming language Brainfuck. I relocated these pages to have a new home on my server.

It is the smallest (I think) Turing complete language, it only has 8 opcodes. This means that you can solve all solvable problems using only 8 opcodes. 😉 The smallest interpreter for this language is only 140 Bytes(!) small (written in C64 (6502) assembly language). If you are a die-hard computer scientists, this will certainly be fun for you. If there is interest, I will rework these pages to be in english and more extensive maybe. Of course there are the inevitable HelloWorld and a Quine (program that prints out itself). You can try out the language right now using the JavaScript based online interpreter.

Just now I finished my last two mandatory (well, semi-mandatory) exams, leaving me with one completely optional exam tomorrow (will do this as a safety guard) and my diploma thesis. Yay! Today it was all about internet programming (JSP and servlets) and XML. Pretty cheap low hanging fruit this.

Device Driver badness

Today I implemented the VolatileImage subclass for WindML. The idea was to hold the image in the Video RAM, which should have the following advantages:

  1. Drawing into the image is much more efficient.
  2. Drawing (blitting really) the image onto the screen is much more efficient.

A first prototype used a normal bitmap in the RAM (not yet video RAM) and I was quite pleased that this worked after 2 hours work or so. This was equivalent to the offscreen image implementation that we had before in Jamaica (which was AWT 1.1 oriented and thus was a simple subclass of Image). However, I was really surprised when I changed some lines of code so that the VolatileImage was allocated in the Video RAM. The performance got much slower. It even got so slow, that you could see the image beeing copied onto the screen. So what was going on? Obviously the source and destination bitmaps (the onscreen and offscreen bitmaps respectivly) are placed inside the video RAM so you would suspect that blitting one on the other would be blazingly fast. Well, the only reason for this enourmous slowdown could only be that it is not the graphics chip performing the blit operation, but the CPU. When the CPU does something like this, it would have to pull the bytes from the source bitmap over the bus, and push them back to the destination bitmap, over the bus again. This is quite a mess on the bus going on I guess 😉

I very much suspect that there is a problem with either with my understanding of the WindML API or with the device driver. The former seems quite unlikely, what use is a bitmap that can be allocated in the video RAM, when you can’t efficiently copy it to the onscreen bitmap? The latter seems more likely. I can guess that the driver supports something like real double buffering (as would be mapped into Java with a BufferStrategy), where a complete offscreen buffer is either copied or flipped. After all, the WindML offers a special API for that even. Supporting double buffering with a VolatileImage requires supporting to blit sub-images from offscreen to onscreen, which is probably slightly more difficult to implement because it would have to be done in h chunks of w pixels each. I’m going to test this on another box with different hardware and/or driver to confirm this or disprove this thesis.

If the API and/or driver would be Free Software I could quickly take a look for myself (and probably hack up the driver to support what I want), but oh well. The crux of proprietary software I guess…

Bug Hunting

If you ever come to hacking on an interpreter, remember the following advice: 1. Develop stuff in very small increments, 2. Test thouroughly after each increment, 3. keep track of this (e.g. using CVS).

I was hunting down a bug in Jamaica’s interpreter the last couple of days. That one was really haunting me. Here’s how I caught it:

  1. Compared the current changes to the version in CVS. Unfortunately I was not following advice #1 above. This one was a rather large patch and digging through it revealed no obvious mistake.
  2. Debugging in GDB. Well, usually this should help but here it was quite pointless. The backtrace was useless as it’s in the interpret() function because the interpreter is just one big loop inside this function. Stepping through it is also pointless because the failure didn’t pop up right at the start, but instead after the zillionth opcode. So where should I have set the breakpoint?
  3. Searching backwards through CVS. It turned out the the breakage was not caused by the current patch, but by one of the patches that I already checked in. At least, that was what I found after going back 2 revisions in CVS. Unfortunately, this patch was also quite big, so I incrementally went from revision-2 to revision-1, only to find out that this one was a different bug from the one that I was looking for (and one that already was solved magically in the current code). ARRRG!
  4. OK. There must be a problem between rev-1 and rev then (not counting the current local patch). Repeat step#3 with this. This enabled me to narrow the problem to the buggy function and I could finally find and fix this bug. It turned out to be a small typo in the end. Why I couldn’t find it in step#1? Well, the variable names d1 and dl are almost distinguishable… Sigh. So I add adivce #4 here: Make up good variable names. Two-letter names like dl definitely are no good.

Ok, back to work now. Gotta finish that WindML VolatileImage and work some more on the interpreter. Ah, and I really should start learning a little for the 3 exams on thursday and friday. Y’know, three of those exams where I never attended the actual courses and do the exams anyway. This time it is ‘Internet Programming’, ‘XML’ and ‘Software Engineering’. Should provide some relaxation from VM and graphics hacking 😉 The best thing is, these are going to be the last (really really last) three exams, except the diploma thing itself. Hurray!