3

I'm currently in the process of designing and developing GUI's for some audio applications made in C++ (using the Juce framework).

So far I've been playing with using bitmap graphics to create custom sliders and dials, by using 'film strip' style images to animate the components (meaning when the user interacts with a slider it triggers a method that changes the offset of a film-strip image to change the components appearance). Depending on the size of the original image and the number of 'frames', the CPU usage level changes quite dramatically.

Firstly, what would be the most efficient bitmap file format to use in terms of CPU consumption? At the moment I'm using PNG images.

Secondly, would it be more efficient to use vector graphics for these kind of graphical components? I understand the main differences between bitmap and vector graphics, but I haven't found any information regarding their CPU usage levels with regard to GUI interaction.

Or would CPU usage be down to the particular methods/functions/libraries/frameworks being used?

Thanks!

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
Liam Lacey
  • 215
  • 3
  • 7

4 Answers4

2

Or would CPU consumption be down to the particular methods/functions/libraries/frameworks being used?

Any of these things could influence it.

Pixel based images might take a while to read off of disk the bigger they are. Compressed types might take more time to uncompress. Vector might take more time to render when are loaded.

That being said, I would definitely not expect that your choice of image type to have any impact on its performance. Since you didn't provide a code example it is hard to speculate beyond that.

In general, you would expect that the run-time costs of the images to happen when they are loaded. So whenever you create an image object. If you create an images all over the place, then maybe its expensive. It is possible that your film strip is recreating the images instead of loading them once and caching them.

Tom Kerr
  • 10,444
  • 2
  • 30
  • 46
0

Before choosing bitmap vs. vector graphics, investigate if your graphics processor supports vector or bitmap graphics. Some things take a long time to draw as vectors.

Have you tried double-bufferring?
This is where you write to a buffer in memory while the display (graphics processor) is loading another.

Load your bitmaps from the resource once. Store them as memory snapshots to avoid the additional cost of translating them from a format.

Does your graphic processor support "blitting"? Blitting is where the graphics processor can copy a rectangular area in memory (bitmap) and display it along with apply optional operations before displaying (such as XOR with existing bits).

Summary: To improve your rendering speed, only convert images from the file into a bitmap form once. Store this somewhere. Refer to this converted bitmap as needed. Next, investigate and implement double buffering. Lastly, investigate and use bit-blitting or blitting.

Other optimization rules apply here too, such as reviewing the design, removing requirements, loop unrolling, passing images via pointer vs. copying them, and reduce "if" statements by using boolean logic and Karnaugh (sp?) maps.

Thomas Matthews
  • 56,849
  • 17
  • 98
  • 154
  • Based on my understanding of the question, this is normal PC hardware (definitely supports accelerated blits), but he's using a translation transform + clipping to select part of the film strip, not directly blitting the appropriate rectangle. Blitting might well be faster. – Ben Voigt Sep 02 '11 at 18:32
  • Some graphic processors can perform blit and clip in one operation. The clip operation would be supplied either as an alpha channel or a matrix. – Thomas Matthews Sep 02 '11 at 18:56
0

In general, calculations for rendering vector graphics are going to take longer than blitting a rectangular region of a bitmap to the screen. But for basic UI stuff, neither should be particularly intensive.

You probably should do some profiling. Perhaps you're redrawing much more frequently than necessary. Or perhaps the PNG is being decoded each time you try to draw from it. (I'm not familiar with Juce.)

For a straight Windows app, I'd probably render vector graphics into a device-dependent bitmap once on startup and then just blit from the bitmap to the screen. Using vector gives you DPI independence, and blitting from a device-dependent bitmap is about the fastest way to paint a block of pixels. I believe the color matching is done when you render to the device-dependent bitmap, so you don't even have the ICM overhead on the screen drawing.

Adrian McCarthy
  • 45,555
  • 16
  • 123
  • 175
-1

Vector graphics was ditched long ago - bitmap graphics are more performant. The thing is that you can send a bitmap to the GPU once and then render it forever more by a simple copy.

Secondly, the GPU uses it's own texture compression. DirectX is DXT5, I believe, but when the GPU sees the texture, it doesn't care what you loaded it from.

However, a modern CPU even with a crappy integrated GPU should have absolutely no problem with simple GUI rendering. If you're struggling, then it's time to look again at the technique you're using. Perhaps your framework is slow or your use of it is suboptimal.

Puppy
  • 144,682
  • 38
  • 256
  • 465
  • Bitmaps perform well for static graphics. For dynamic graphics, bitmaps perform ok with a single degree of freedom, but as soon as you need more than that, prerendering graphics rapidly become prohibitively expensive in terms of memory requirements. – Ben Voigt Sep 02 '11 at 19:59
  • @Ben Voigt: For the use case the OP is describing, just moving a bitmap will be fine. – Puppy Sep 02 '11 at 23:40