Drawing speed


#1

Howdy,

I’m thinking about using juce for a sort of interactive graphics/audio thingy. I’m wonding if the 2D drawing stuff in Juce is appropriate for rendering 30-60 times a second, or if I should roll my own stuff in opengl. I’m not planning on doing anything too fancy, but I’d like things to look smooth and not pin the processor down.


#2

I’ve done some unscientific testing and the results aren’t so promising. Can I get a final word before I move onto using the OpenGLCanvas.

Thanks!


#3

Check out this thread for my experiences with 2D drawing of large objects. Basically I’m getting 40-50% cpu utilization on large (> 200x200) components that update 30x sec.

  • kbj

#4

It depends entirely on what kind of thing you’re drawing… some things are fast, some aren’t. The only way to really see is to have a go.


#5

does the image format effect drawing speed?

i.e. png vs jpeg vs bmp???


#6

The images are all decompressed before they’re drawn, so no, that won’t affect it.


#7

Fair enough, I’ll play around with it.

I’ve noticed that things sped up a fair amount once I removed the gradient brush, as would be expected.

Is there a way to, say, render a fancy background that will remain fairly static once (into a buffer or something?) and then draw my moving stuff on top more often?

I come from a console game development background where we peg the CPU all the time because we’re the only thing using it. I’m thinking that isn’t the friendliest thing to do on a desktop app :slight_smile:


#8

You want Component::setBufferedToImage()…


#9

Ah, very nice. Thanks Jules, I’ll try this stuff out when I get home from work.


#10

Another thing to try is enabling GDIPLUS in juce_win32_Windowing.cpp. Certain things may be slower, but I’ve found quite a bit of speedups in my paint routines.

  • kbj

#11

Thanks for the tip, but my main target is OSX. Maybe once we get quartz acceleration…

In the mean time, I think i’m just going to use OpenGL. I need to brush up on my OpenGL anyhow.

A curious thing though, maybe Jules can explain. On windows 2000, when my sample app was in the foreground, it would suck up 10-20% CPU. When I bring another window forward CPU use drops down to near 0. I can still see my window animating as smoothly as ever… What’s going on here?


#12

[quote=“dockthepod”]Thanks for the tip, but my main target is OSX. Maybe once we get quartz acceleration…

In the mean time, I think i’m just going to use OpenGL. I need to brush up on my OpenGL anyhow.

A curious thing though, maybe Jules can explain. On windows 2000, when my sample app was in the foreground, it would suck up 10-20% CPU. When I bring another window forward CPU use drops down to near 0. I can still see my window animating as smoothly as ever… What’s going on here?[/quote]

Sounds like magic to me… can you see that happening with things like the demo app? It might just be repainting less often, but still often enough for the animation to be smooth.


#13

I just tested the demo app on my XP machine at work… I think that as I cover the window up with another window bit by bit, the CPU usage drops. Maybe you’ve got some stuff in there that only draws what can be seen and this accounted for the drop I saw. Interesting stuff.


#14