Question

All you Stackoverflowers,

I was wondering why GUI code is responsible for sucking away many, many cpu cycles. In principle, the graphical rendering is far less complex than Doom (although most corporate GUIs will introduce lots of window dressing). The event handling layer is also seemingly a heavy cost, however, it seems that a well-written implementation should switch between contexts efficiently on modern processors with a lot of memory/cache.

If anybody has run a profiler on their big GUI application, or a common API itself, I’m interested in where the bottlenecks lie.

Possible explanations (that I imagine) may be:

1. High levels of abstraction between hardware and application interface
2. Lots of levels of indirection to the correct code to execute
3. Low priority (compared to other processes)
4. Misbehaving applications flooding API with calls
5. Excessive object orientation?
6. Complete poor design choices in API (not just issues, but design philosophy)

Some GUI frameworks are much better than others, so I’d like to hear varied perspectives. For example, the Unix/X11 system is much different than Windows and even than WinForms.

Edit: Now a community wiki – go for it. I have one more thing to add — I’m an algorithms guy in school and would be interested if there are inefficient algorithms in GUI code and which they are. Then again, it’s probably just the implementation overhead.

Answer 1

I’ve no idea generally, but I’d like to add another item to your list – font rendering and calculations. Finding vector glyphs in a font and converting them to bitmap representations with anti-aliasing is no small task. And often it needs to be done twice – first to calculate the width/height of the text for positioning, and then actually drawing the text at the right coordinates.

Also, most drawing code today relies on clipping mechanisms to update just a part of the GUI. So, if just one part needs to be redrawn, the code actually redraws the whole window behind the scenes, and then takes just the needed part to actually update.

Added:

In the comments I found this:

I’m also very interested in this. It can’t be that the gui is rendered using only the cpu because if you don’t have proper drivers for your gfx-card, desktop graphics render incredibly slow. If you have gfx-drivers however desktop-gfx go kinda fast but never as fast as a directx/opengl app.

Here’s the deal as I understand it: every graphic card out there today supports a generic interface for drawing. I’m not sure if it’s called ‘VESA’, ‘SVGA’, or if those are just old names from the past. Anyway, this interface involves doing everything through interrupts. For every pixel there is an interrupt call. Or something like that. The proper VGA driver however is able to take advantage of DMA and other enhancements that make the whole process WAY less CPU-intensive.

Added 2: Ah, and for OpenGL/DirectX – that’s another feature of today’s graphics cards. They are optimized for 3D operations in exclusive mode. That’s why the speed. The normal GUI just utilizes basic 2D drawing procedures. So it gets to send the contents of the whole screen every time it wants an update. 3D applications however send a bunch of textures and triangle definitions to the VRAM (video-RAM) and then just reuse them for drawing. They just say something like ‘take the triangle set #38 with the texture set #25 and draw them’. All these things are cached in the VRAM so this is again way faster.

I’m not sure, but I would suspect that the modern 3D-accelerated GUIs (Vista Aero, compiz on Linux, etc.) also might take advantage of this. They could send common bitmaps to the VGA up front and then just reuse them directly from the VRAM. Any application-drawn surfaces however would still need to be sent directly every time for updates.

Added 3: More ideas. 🙂 The modern GUI’s for Windows, Linux, etc. are widget-oriented (that’s control-oriented for Windows speakers). The problem with this is that each widget has its own drawing code and associated drawing surface (more or less). When the window needs to get redrawn, it calls the drawing code for all its child-widgets, who in turn call the drawing code for their child-widgets, etc.. Every widget redraws its whole surface, even though some of it is obscured by other widgets. With above mentioned clipping techniques some of this drawn information is immediately discarded to reduce flickering and other artifacts. But still it’s lots of manual drawing code that includes bitmap blitting, stretching, skewing, drawing lines, text, flood-filling, etc.. And all this gets translated to a series of putpixel calls that get filtered through clipping filters/masks and other stuff. Ah, yes, and alpha blending has also become popular today for nice effects which means even more work. So… yes, you could say this is because of lots of abstraction and indirection. But… could you really do it any better? I don’t think so. Only 3D techniques might help, because they take advantage of GPU for alpha-calculations and clipping.