Could be a timing issue then, I guess… If you can create a mini app that demonstrates it, I’d be glad to have a quick look.
OK, let me think how I can obviously demonstrate it to you.
Hi Jules,
I have created a little demo app, that demonstrates the slowdown I’m talking about. There’re two executables built from the same sources, but with different Juce - one with old Juce and one with new Juce. Sources are quite simple, based on your HelloWorld example app. Both executables, source files and description are archived and can be downloaded here: http://chaoticdaw.com/assets/JuceCompare.zip.
Jules, have you looked at the demo? Do you have any comments or questions?
Admittedly I’m running windows in a VM, but both look identical on my machine. Except that the new one uses 1-2% cpu, and the old one uses 2-3%…
The Timer frequency is only an approximate time - there’s no guarantee at all that it’ll be anywhere near what you ask for, because it’s at the mercy of how long all the other timers and events take to complete, and the order in which they all happen to occur.
It’s very strange, that in both demos timers work with the same speed to you. On usual windows system there’s gigantic difference in Timer speed and visible difference in usual re-rendering speed.
Did I get right, that in new Juce there’re some extra timers and events introduced in application loop, that make Timer work way slower on the same interval setting? As you can see, I myself don’t add any extra timers or events - I just compile absolutely the same app, but with different Juces. And then, do you mean, that to keep the same smoothness in animation, we all need to reduce Timer interval when moving to new Juce?
Maybe reduced Juce graphic and Timer speed is not an issue to you at all? Can you then please advise me how I could fix the terrible bug with RectangleList::consolidate on the old Juce graphic system? I would be very much obliged to you for that.
Of course it’s an issue. But your app is using 2% cpu and looks absolutely fine to me, so that’s not exactly what I’d call a performance problem!
The timer speed is calculated correctly as far as I can see - could be that the old code was actually firing too fast. If you can show me some figures that show the actual firing intervals to be really wildly different from the numbers you request, then I’ll take a look - but the code looks pretty sound.
I guess Timer issue is not a performance problem. Actually I distinguish two different (but maybe somehow connected) problems here - one is that the Timer callback is called with much less frequency than previously with the same interval set and the second problem is that the rendering of the overall interface is also slower than previously (even if don’t use vertical lines). I imply here, of course, that my own code is always the same - the only difference is the Juce version I use for compilation. When I compile with old Juce - everything is fast and smooth. When I compile with new Juce - nothing is fast and smooth.
The app I attached clearly demonstrates both problems on my system - the upper small bar goes much slower on new Juce and the lower big bar also goes visibly slower on new Juce when you drag it with mouse. Probably you need clean Windows system, not VM, to see that. I don’t see any better way to show you the problem now.
So, the only way to keep smoothness, I see, is to stick with old Juce. Therefore I’m continuing to ask you for help with that slowdown bug. Is it too hard to fix it on old Juce? How would you fix it If i’d reported it months before you reworked Juce graphics?
Do you add a fixed amount to the bar’s position each time your timer fires? Because if so, of course it’ll be different - it’ll be different on every machine and every platform where the timer schedule might vary slightly. If you want a constant-speed animation you need to actually look at the current time and use that to work out how far to move your object.
TBH I’m not even sure what you mean about the consolidate method being slow - it’s not changed for a very long time. But I’ve no time to spend mucking around with old versions anyway…
Hey, I’m talking about a single platform and a single machine here, where the only difference is Juce! Did you ever see FL Studio? It’s animation and interface rendering works always smooth independently on which machine and which Windows version you use, although they also use plain timers for it. Compared to this, my app (actually — any app with complex rendering) works smooth everywhere with old Juce only.
Is it so hard to point how was the bug with slowdown I originally reported in this thread fixed? I just want to fix it in the same way on the old Juce code. If you don’t remember, then I can make a citation for you:
And I’m talking about writing proper code that doesn’t make assumptions about the accuracy of a timer class which is inevitably going to vary for many different reasons, the version of juce being just one of them.
I don’t understand what you expect me to do - are timers not doing their job properly? Are you saying they run too slowly? If so, show me some evidence and I’ll sort it out. There’s no actual performance problem, so why not just repaint more quickly if it’s not smooth enough?
I can’t “fix” the rectanglelist. Consolidation is an algorithm that takes n-squared time, so the more rectangles, the slower it’ll go. The new code doesn’t use rectangle lists, it uses edge tables instead.
I’m just stunned by the fact that timer accuracy can vary so far. To achieve the same smoothness now I must use 10 ms interval instead of 30 ms. What will be on the next Juce update? 1 ms interval to keep smoothness? And anyway, timer issue is not the only problem - as I said, the overall rendering became visibly slower.
Is it possible to use edge tables in the old Juce in the same way they used in the new Juce?
I’m getting a bit exasperated now… you just don’t seem to be thinking about what I’m saying.
What does “visibly slower” mean? There’s only one thing that will limit the refresh rate, and that’s if you hit 100% cpu. Your app is using 2% cpu. So you just need to repaint it more often. End of discussion.
Like I’ve said about ten times: if you think the timers are broken or incorrect, prove it, and I’ll fix it. But unless you show me some numbers, then you can’t claim that the old code was correct or that the new code is wrong. It might indeed be different, but that proves nothing. Just because your own app used to be smoother, that doesn’t mean it was correct.
Yes. Just rewrite the entire rendering engine. Shouldn’t take more than a couple of months.
Sorry Jules, but your exasperation is only the result of you permanent inattention to what I several times described from various points. I clearly stated, that there’re two different problems - one with timer and one with the overall graphics rendering. The timer problem is that it’s less frequent on the same interval and the rendering problem is that it’s just SLOW. Of course it hits 100% CPU thus it’s a performance issue of Juce graphics. My demo app separately demonstrates both problems and everything is described in text file I included in archive. If you can’t or just don’t want to test it by running on a machine with clean Windows system then okay, let’s leave it as is.
Just for the record, in case anyone reads this and thinks the graphics have somehow become crap, I’d just like to make the point that the new rendering engine is faster for some things, and slower for others, and about the same overall.
And as I’ve said a few times before, one of the things it’s not so good at is drawing lots of long vertical lines, because these are now rendered as paths. Since your demo does nothing but fill the screen with as many long, vertical lines as it possibly can, then it’s not exactly a huge surprise to find that it goes more slowly than the old version. Try using a tiled image instead and it should go much faster.
I think I can prove the contrary - it’s not the same overall. Actually, the overall rendering works slower now, independently on whether you use vertical lines or not. I reworked my demo app to draw the draggable bar with pixels, instead of vertical lines and the result is the same - old Juce renders it several times faster than new Juce. You can download it here: http://chaoticdaw.com/assets/JuceCompare2.zip. I work in Windows system, so my demo app is Win32-based. It’s very simple - there’re two bars - the small one and the big one. The big one demonstrates rendering speed - you can drag it with mouse and see how fast Juce renders it. While old Juce renders it fast independently of it’s length and almost doesn’t affect small bar animation, the new Juce renders it visibly slower as the bar gets longer and hardly affect small bar animation.
Note, that now I’m talking about the second issue - rendering speed, not about the timer frequency.
No shit? Drawing thousands of pixels is slow? I could have told you that and saved you the trouble.
The new code has a higher overhead per drawing op (proportional to the vertical height involved). But it’s faster at large areas and complex clipping regions, and can do drawing operations that the old stuff couldn’t handle at all.
If you’re drawing a bar, draw it as a rectangle or path, and it’ll be fast. If you’re drawing a pattern, use a tiled image. The software renderer will do a good job of that, and when there’s support for Direct2D, those things will happen even faster in hardware (on the mac and iphone, they’ll already be done by CoreGraphics).
The sad thing here is when it comes to more or less complex and detailed interfaces, the overhead per drawing op inevitably becomes critical. I pedantically followed all your suggestions for new engine - used tiled images for patterns, used paths, avoided vertical lines, etc. but nothing of that made my app speed even equal to what is was previously, not to speak of more faster.
Well, let me just stick with old Juce engine. I definitely like more how it handles various graphic stuff.