Qball's Weblog

Improving drawing performance

Tags Squishybox 

Drawing a nice scrolling text on my squeezebox touch caused a 19% cpu usage. This is very doable, but I wondered how to improve this.

So perf to the rescue.  Trying to see what was actually hitting the cpu.  Turned out that a lot of time was spend in the drawing routines. (the whole screen was redrawn on update).  This was something I wanted to change to a smarter system, so I decided to implement a system that gave me a list of rectangles on the screen that needed to be redrawn and only redraw those parts on the screen. (Each widget has it own surface that is then blitted to the screen).

Being a good example of being smart turning bad, this caused the most screwed up artifacts on the device. (Running fine on my pc.). So where it went wrong?  The SBT implements double-buffering with 2 buffers that are swapped. (instead of write-back method).  So when updating the background, this is updated on the 1st buffer, but not the second. So if on the next frame I only update the slider, you see the old background again with a new slider rendered on top of it. I can tell you, this gives the most weird effects.

So HW double-buffering and partial redrawing wasn’t going to work.  No double-buffering causes tearing (offcourse). So the next best solution was todo ‘fake’ double buffering. I keep a software Surface that I (at once) write after updating it (using the partial update method) to the (single-buffered) video buffer.  This solved the tearing issue off single-buffer but was still up to 50%! faster then the double-buffer method where I had to re-render the whole surface.

It ain’t pretty, but it works.  (I still need to combine overlapping exposed rectangle in a smart way. ).

So another step forward made..