2010-09-10

Performance Problems - Not Where You'd Expect

The new rendering system in Woopsi is coming along nicely. In most areas it increases rendering speed and reduces flicker. In one area, though, it hasn’t been an improvement at all. Scrolling has become a problem.

In the old system, scrolling regions were extremely quick, mainly because most of the scrolling is done by just using the DMA to copy the existing pixels to a new location. In the new system, however, scrolling is sluggish and annoying. It seems to take more than one frame to perform a single scroll operation, which results in the display lagging behind the stylus and the system appearing to be, well, a bit rubbish.

I’ve already made one major optimisation. Instead of asking every gadget to draw every damaged rectangle until there are no rectangles left (which results in dozens of pointless, complex clipping operations), Woopsi uses the hierarchy of the gadgets to its advantage. If a parent gadget does not intersect a damaged rectangle, there is no way for its children to intersect it either. In avoiding trying to draw those children we save a lot of time.

However, this did not solve the scrolling problem. So what could it be? More to the point, how can it have happened, as the scrolling code hasn’t actually changed?

I had a few guesses. Perhaps the scrolling operation was running more than once. Putting break points into the Xcode version of Woopsi quickly killed that idea. Perhaps I need to cache the contents of ScrollingPanels in some sort of off-screen bitmap - maybe it’s all the redrawing that is a problem. But it couldn’t be that - there weren’t any problems before. Perhaps the list of newly-revealed rectangles that need to be redrawn that is returned by the scrolling routine is inaccurate. Testing it overturned that idea.

So I turn to Xcode’s “Instruments”, something that I wish Visual Studio would copy. Running Woopsi through the CPU Sampler suggests that the only thing Woopsi is doing is creating Rect objects. Creating rectangles is making Woopsi’s scrolling rubbish? That makes no sense.

Except, perhaps it does.

All of the new rendering functions create WoopsiArrays of Rect objects. As the inital size of a WoopsiArray is 100, and as they store objects, not pointers to objects, that means that each function call to one of these methods creates hundreds of Rect objects. Worse, these functions are recursive. There are probably tens of thousands of Rect objects being created every time the screen redraws.

I tried switching to arrays of pointers-to-rect objects, but quickly got bogged down in recursive memory allocation hell. Instead, I altered the WoopsiArray class so that it accepts an initial reserved size parameter. In most cases, none of the methods needs more than 4 rects in a list, so I’ve gone with that as the initial size. I’ve also changed the way that the array class resizes itself; it now doubles in size every time it needs to allocate more space instead of increasing by 100 elements. I believe this is the behaviour of the STL’s vector class.

Surprisingly enough, these very minor changes fixed the scrolling problems and boosted the speed of Woopsi everywhere else. I’m not sure I can remember it being this quick.

It’s a very old programmer’s cliche, but it’s true. Performance problems aren’t always where you’d expect.

2009-04-22

Happy Belated Birthday, and More Event Stuff

It was the blog’s birthday on April 11th. I’d intended to put up a birthday post like I did last year, and maybe a celebratory Woopsi app, but exam work got in the way. Ah well.

Anyhoo, I made some more Woopsi changes nearly a month ago that I haven’t been able to post about yet, so here’s some info on those.

One of the lingering problems with the Gadget class has been the way it overloads the draw() method. There are two draw() methods, one without parameters, and one with a single parameter (a Gadget::Rect). The first method works out which parts of the gadget are visible, whilst the second actually draws those visible parts. Sounds good, but in practice it causes problems.

There is a bug in GCC (or a weird C++ behaviour; let’s assume it’s a bug in the compiler and not a design flaw in the language) that prevents this arrangement from working. If we create a subclass of gadget (let’s call it “SubGadget”), we want to override the draw(Rect) method so the gadget can define how to draw each visible region. However, we don’t want to override the draw() method, as this is identical for all gadgets. Unfortunately, we can’t override one without also overriding the other. The compiler complains. As a workaround for this I have been overriding draw() with a method that just calls the base method, but this is clunky.

As a proper fix, the draw() method is now called “redraw()”. This change will probably break your code if you have created your own gadgets.

There are a few more changes in the event system. Previously, whenever a selection was made in the context menu, the gadget that “owned” the menu raised an event indicating the selection. It was then the programmer’s responsibility to check the context menu gadget itself to determine which value had been chosen. This is no longer the case - the handleContextMenuSelectionEvent() method now receives a reference to a “ContextMenuEventArgs” object that contains a pointer to the menu item that was selected. Much simpler to work with.

In other changes, the WoopsiArray and LinkedList classes no longer contain the “begin()” methods. This was left over from when Woopsi switched from the STL vector class to the WoopsiArray, a change in which I’d purposely made the WoopsiArray a drop-in replacement for the vector. The “begin()” was just a stub method, though - the WoopsiArray does not implement the STL iterator code, and begin() simply returned a zero. The WoopsiArray uses indexes internally, not pointer arithmetic, to navigate its contents.