0
0
Drawing On The Internet Tablet Screen
From http://www.maro.net/ossramblings.php?itemid=371
Posted on 2007-09-15 12:48:04 UTC.
There are some things that you just have to do differently when you're programming for a small device like the Nokia n800. The processor is just not as powerful as your desktop.
One of those things is how you draw graphics.I've been working on the Python GTK Kinetic scrolling widget to get it's speed enhanced and finally made a breakthrough.
The first thing I figured out was that since I'm not always letting the event call the realize handler, the standard GTK double-buffering wasn't happening on it's own. Once I enabled that, I was able to rip out all of my code related to double-buffering, and that improved performance somewhat.
Still, it was just too slow.
I did some digging and all of the documentation for GTK says "Use pixbuf's to store images". It's easier, they say. It's more feature rich. What they neglect to mention is it's also darned slow. On a desktop you'd never notice, but with a 300 MHz handheld with a slow screen, you notice very easily. Painfully slow.
Fortunately I found a simple fix. I convert all of the pixbuf's to a device-dependent pixmap that is tied to the screen depth and format. Drawing a pixmap onto the screen is lightning fast. So fast, in fact, that I had to tweak other aspects of the scroll widget to keep it from going too fast. Using a pixmap also gave me a drawable that I could use for pre-rendering pango text. This allows me to draw the button captions just one time and keep that cached on the graphic for later quick drawing. Drawing text all over the screen when you're going for 30 or 40 frames per second isn't really very possible, but with pre-rendering it one time it eliminates that delay as well.
I was talking with the Kagu media player developers in IRC and one asked me how it would do with 600+ entries in the scroll list. We were concerned that it would take too long to load and use too much memory. I made a quick test and found it to be extremely fast and use a _lot_ less memory than we expected. I'm quite pleased with it now.
Download the sources to use it in your own GPL licensed application.
One of those things is how you draw graphics.I've been working on the Python GTK Kinetic scrolling widget to get it's speed enhanced and finally made a breakthrough.
The first thing I figured out was that since I'm not always letting the event call the realize handler, the standard GTK double-buffering wasn't happening on it's own. Once I enabled that, I was able to rip out all of my code related to double-buffering, and that improved performance somewhat.
Still, it was just too slow.
I did some digging and all of the documentation for GTK says "Use pixbuf's to store images". It's easier, they say. It's more feature rich. What they neglect to mention is it's also darned slow. On a desktop you'd never notice, but with a 300 MHz handheld with a slow screen, you notice very easily. Painfully slow.
Fortunately I found a simple fix. I convert all of the pixbuf's to a device-dependent pixmap that is tied to the screen depth and format. Drawing a pixmap onto the screen is lightning fast. So fast, in fact, that I had to tweak other aspects of the scroll widget to keep it from going too fast. Using a pixmap also gave me a drawable that I could use for pre-rendering pango text. This allows me to draw the button captions just one time and keep that cached on the graphic for later quick drawing. Drawing text all over the screen when you're going for 30 or 40 frames per second isn't really very possible, but with pre-rendering it one time it eliminates that delay as well.
I was talking with the Kagu media player developers in IRC and one asked me how it would do with 600+ entries in the scroll list. We were concerned that it would take too long to load and use too much memory. I made a quick test and found it to be extremely fast and use a _lot_ less memory than we expected. I'm quite pleased with it now.
Download the sources to use it in your own GPL licensed application.