If you saw my other question, well, there is still a little problem:

Click here to watch on youtube

Basically, the frame rate is very bad on the actual device, where for some reason the animation is scaled (it looks like the left side on the video). It is quite fast on the simulator where it is not scaled (right side).

For a test, I submitted this new changeset that simply hard-codes the smaller size (in SDL_CreateWindow() and in glViewport()), and as you see in the video, now it is slow even in the simulator (left side shows the small size, right side shows the original size -- otherwise the code is the same).

I'm clueless why it's soooo slow with a smaller galaxy, in fact it should be FASTER.

The question is not about general speed optimization like reducing screen resolution or joining glBegin(GL_POINTS)/glEnd() blocks.

Update: For a test, I simply reduced the screen size to 320x480 and compiled it to OS X desktop -- got the same speed as with 800x800, so this size-specific slow-down is on iOS only. Will post this on the SDL mailing list now.

  • \$\begingroup\$ The reason why it's faster on the simulator is due to the fact that the actual IOS simulator implementation has nothing to do with real IOS devices architecture, it's a software made to take advantage of your computers CPU and Graphics Card capabilities, which will always be faster than curren IOS devices. \$\endgroup\$ – Shivan Dragon Nov 19 '12 at 23:06
  • 1
    \$\begingroup\$ thanks @shivan-dragon, but if you check out the youtube link I posted you will see speed difference of the two versions BOTH RUNNING ON THE SIMULATOR (and my question was: why is that? and why it's not happening on OS X, only on iOS?). I mentioned the real device only because SDL does an autoscaling there which I needed to manually do on the simulator for test purposes. \$\endgroup\$ – Gabor Nov 20 '12 at 8:35

Comparing iOS Simulator and OSX OpenGL speed is pointless. OpenGL ES on iOS Simulator is a software renderer, and OpenGL in OSX is GPU accelerated. The performance characteristics can thus be expected to be completely different.

More to the point, the faster image with the galaxy on the right side of the screen culls more than half of the points against the view frustum. That is a very fast operation and already there you should get 2x performance. Further, the amount of overdraw in the centered galaxy is far higher since you have a smaller galaxy with the same point size as the larger galaxy to the right. Each overdraw increase blending computations. You see that as the brightness increasing.

In short, you have 2x shading work and much more blending work. To remedy this, decrease the point size for the centered galaxy. You may also want to cut the number of points in half for the centered galaxy to get equal performance.

| improve this answer | |
  • 1
    \$\begingroup\$ Thnx, I reduced both glPointSize and the number of stars in NBodyWnd and it's smooth enough now; and you definitely answered my question; of course it's not nearly as fast as the original youtu.be/AD9OV1Zrs4I but maybe that's just because my iPod cannot catch up with a Linux desktop \$\endgroup\$ – Gabor Feb 6 '13 at 14:22
  • \$\begingroup\$ @ber4444 Why not award the bounty? \$\endgroup\$ – rasmus Feb 12 '13 at 23:29
  • \$\begingroup\$ It was automatically awarded, you got 75 points according to your profile. Let me know if I should do something else... \$\endgroup\$ – Gabor Feb 14 '13 at 10:09
  • \$\begingroup\$ @ber4444 Thanks. I thought that you only get half the bounty if it is automatically awarded. Apparently I was wrong. \$\endgroup\$ – rasmus Feb 14 '13 at 16:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.