Meanwhile I’ve done some tests with the different versions on different systems.
I have tested the 32bit and 64bit relase versions on three different systems.
All systems have graphic cards not older than 3 years with shader support. Two of them are ATI cards and one is an NVIDIA.
The results are always the same: between 15ms and 30ms rendering time when I use the current version and between 0.5ms and 2ms when I use the version before March 13.
The problem is definetly not specific to one system. The OS of all systems was Win 7 64 bit.
To reproduce the problem I compiled the Juce Demo as 32 and 64 bit release versions once using the current version and once using the older commit.
I included a small info file with infos about the versions and some hints how to test this, so that the results of others are compareable.
Could you please download the different versions and post your results here.
Thanks.
That’s what I expected.
In my case the differences have even been greater.
So some changes of the following commit are responsible for a huge performance loss of the OpenGL Renderer on Windows plattforms:
Revision: b338698e346d3cb14e33e568f838a7e8523bb544
Author: jules
Date: 15/03/2012 12:13:38
Message:
OpenGL: removed the fixed-function rendering code, replacing it with a simple software renderer that blits its results to the GL context. Removed the public OpenGLGraphicsContext class, replacing it with a createOpenGLGraphicsContext() function which returns an appropriate shader-based or software-based renderer object.
It’s really no help to quote all these numbers or get other people to do the same test - I need to know why this is happening, not by how much! Even if it only happened on one machine, there’d still be a problem to fix. I just haven’t a clue what it is, and throwing endless timing statistics at me is not useful!
I’ve already looked through that diff and really can’t see anything that looks significant. I’ll do some more investigating when I get chance, but any suggestions (other than lists of timings!) would be appreciated!
I think that the intention is not so much to quote the difference in performance, but to illustrate that we know with certainty where the problem lies - it is exactly in those commits!
"When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.” - Sherlock Holmes
The difference has to be somewhere in there. Is it possible to break the commit up into smaller pieces and figure out which piece caused it? Can we take the commit and factor out any changes that are not openGL specific, and reduce the search-space? This question is more aimed at friscokid.
Yes, I know… Annoyingly, the commit involves a huge number of changes - all just ripping out old code, but perhaps a typo crept in there somewhere which is messing something up. Strange that it’s only a Windows problem, and not OSX, as there’s very little platform-specific code involved.
juce_OpenGLComponent.cpp seems to have not that many changes, is it possible to mix the old version with the other new files? If it is still slow then we could possibly rule that file out.
juce_OpenGLContext.h and juce_OpenGLContext.cpp didn’t change much either, and the class declaration has a trivial difference. It should be possible to use the old OpenGLContext object with the rest of the new code, and eliminate that as a source of problems.
But you already looked and didn’t find anything so maybe my ignorant approach will uncover something. I admit, I don’t understand anything of what I’m loooking at in the Open GL code (maybe thats a good thing).
I experimented with the numQuads setting, too, but that didn’t make any difference.
I can confirm that crash on exist, but I know that it disappeared in one of the next commits within a week.
I’m trying to replace the code step by step and see what happens, but I have to admit that I don’t even understand 10% of what Jules is doing there, so it’s moreless a trial and error procedure…
I can confirm that the problem is isolated to OpenGLGraphicsContext, as Jules pointed. I brought everything except that file up to the post-OpenGL rewrite and it did not slow down. It is only with the introduction of the new OpenGLGraphicsContext that the slowdown occurs.
I’ve checked the OpenGLGraphicsContext.cpp and could not find any relevant changes up to line 2805 (old code: “class ClipRegion_RectangleList_Shaders : public ClipRegion_RectangleListBase”) where the code was changed to “class ClipRegion_RectangleList : public ClipRegionBase” (line 1686 in the commit that intruduced the problem).
Starting from this line thre are a lot of changes because of the removed “ClipRegion_RectangleListBase”. There I got a bit lost, but I’m pretty sure that up to this part there are no changes to could make the difference.
Maybe something having to do with the context width and height? These parameters were introduced with the changes, and the comment says that they are for scaling the coordinate system. Perhaps a much larger buffer than necessary is being allocated and then being scaled down at draw time?
You could set a breakpoint in the original code and look at the width/height of the context, and then check out the changed code and compare the same values in the debugger.
I have good news and bad news.
The good news: I found the problem why things slowed down with the commit on March 13. at 12:13:38.
#if JUCE_USE_OPENGL_SHADERSxxx
if (target.context.areShadersAvailable())
return new ShaderContext (target);
#endif
at line 2215 should be
#if JUCE_USE_OPENGL_SHADERS
if (target.context.areShadersAvailable())
return new ShaderContext (target);
#endif
when the JUCE_USE_OPENGL_SHADERS is corrected the performance is great.
The bad news: This line IS correct in the current version 2.
So there must have been other changes not the ones from March 13. that are responsible for the problem in version 2.
I’ll try to find the commit that reintroduced the problem, but the one from March 13. was simply a typo.
The changes that are responsible for the reintroduced performance problems first appear in the folling commit:
Revision: 04c2d6cfc1c5228bca3346ead6a821784a4238a7
Author: jules
Date: 03/04/2012 15:51:22
Message:
Added some GL error handling and tweaks to support older PC builds.
The previous version is great:
Revision: 074a8c05dd04f5001fc4721b47371882f918be40
Date: 03/04/2012 14:31:27
The demo of the version that introduced the problem does not compile out of the box, you first have to correct a typo that was corrected by Jules in later commit:
change line 178 of the file OpenGLDemo.cpp from
to
and the demo will compile fine.
Now we have to find the changes that caused the problem.
At least we know where to search…
