Window New Graphics Performance test code

Windows
1

I built a demo app to show my problem in another thread.

Just extract the rar to juce\extras and then build and run. It has a slider in a window. When you drag the slider it repaint the main component with simple lines and colors. When dragging it you can check the CPU usage. It’s about 40% for me.

Copy the project to the same position of a old juce library (before low level graphics change). Rebuild the project and run. Drag the slider and watch the CPU, it’s about 15% for me.

Any ideas?

Thanks

2

This might be because you’re drawing vertical lines with drawLine rather than fillRect or drawVerticalLine. I think the old code had an optimisation that detected that and used a faster draw method, but the new stuff might not do that.

Anyway, it’s always best to never call drawLine unless you really do need an angled line.

3

[quote=“jules”]This might be because you’re drawing vertical lines with drawLine rather than fillRect or drawVerticalLine. I think the old code had an optimisation that detected that and used a faster draw method, but the new stuff might not do that.

Anyway, it’s always best to never call drawLine unless you really do need an angled line.[/quote]

I changed the paint code into this:

g.setColour(Colours::grey);
g.fillAll();

float step  = getWidth() / 128.0f;
int i;
for(i=0;i<128;i++)
{
g.setColour(Colours::black);
g.drawVerticalLine(i*step, 0, getHeight());
}

The result is still very different between old and new juce. It’s about 1% vs 15% for me. I uploaded both release binary for your reference.
http://www.maizesoft.cn/misc/wingraphicscompare.rar

4

Hmm, that doesn’t make much sense. I’ll take a look asap and see what I can find out.

5

Did you find anything?

6

Yes. You’re just making heavy use of the one graphics operation that is much slower in the new version - long vertical lines. Everything else is as fast as it used to be, but those now have to be rendered as rectangles so they can be correctly clipped to complex clipping regions, whereas in the old version they were done as a special case.

TBH I don’t know how I could possibly optimise them, and if you weren’t filling the screen with them you wouldn’t have noticed the difference. But if you’re drawing a screenful of repeating patterns like that, it’s probably much quicker to fill it with an image brush anyway.

7

[quote=“jules”]Yes. You’re just making heavy use of the one graphics operation that is much slower in the new version - long vertical lines. Everything else is as fast as it used to be, but those now have to be rendered as rectangles so they can be correctly clipped to complex clipping regions, whereas in the old version they were done as a special case.

TBH I don’t know how I could possibly optimise them, and if you weren’t filling the screen with them you wouldn’t have noticed the difference. But if you’re drawing a screenful of repeating patterns like that, it’s probably much quicker to fill it with an image brush anyway.[/quote]

Thanks, I will try the imagebrush trick.

8

[quote=“jules”]Yes. You’re just making heavy use of the one graphics operation that is much slower in the new version - long vertical lines. Everything else is as fast as it used to be, but those now have to be rendered as rectangles so they can be correctly clipped to complex clipping regions, whereas in the old version they were done as a special case.

TBH I don’t know how I could possibly optimise them, and if you weren’t filling the screen with them you wouldn’t have noticed the difference. But if you’re drawing a screenful of repeating patterns like that, it’s probably much quicker to fill it with an image brush anyway.[/quote]

Is it possible for me to swap that old code back?

9

What old code?

10

What old code?[/quote]

I mean is it possible for me to replace the slow new drawverticalline code with the fast old drawverticalline. Is that part of code very compact? or it won’t work with other juce components after replace?

11

Do you really think I would have written a new, slow routine if it was remotely possible to use the old, fast one!?