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…

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: