Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

lockCanvas() really slow

Testing my game on a slower device (Orange San Francisco aka ZTE Blade) and I have been getting an appalling frame rate.

I put some debug code into the draw loop and discovered the following line is taking over 100ms:

c = mSurfaceHolder.lockCanvas();

Anyone else seen this behaviour? I temporarily replaced the surfaceview by extending View and implementing onDraw(), and I got a much better framerate.

Although in general surfaceView is much faster on my HTC Desire. I am suspicious this may be a Android 2.1 problem. I'm contemplating rooting the phone and upgrading it to 2.2 if possible, but I did want a device running on 2.1 so that might be counter-productive in the long run.

** update **

I've been working on this some more, and have discovered some more puzzling aspects to it.

I rooted the phone and installed 2.2 and the problem still happens. When the app is first started, the lockCanvas is working as expected (0-1 ms). Then at some point during my initialisation, lockCanvas suddenly starts taking approx 100ms.

It might be worth pointing out that I am loading my assets in an Async task, so that I can display a loading screen.

Despite my best efforts to pin down what the program is actually doing when the slowness occurrs I was not able to do so. In fact when I run it in debug mode and single step, it works fast!

Now I discovered that if I add a delay in the constructor of my SurfaceView (of about 10 seconds), the slowness doesn't occur and all works fine.

However if you press Home, and then switch back, the slowness comes back.

I'm pretty much at the end of my tether on this stupid illogical problem! I've got a mind to put it down to a device specific problem.

I feel it could have something to do with memory usage. Maybe something is being swapped out and it affects the video ram?

I'd be interested in theories at least.

like image 988
Kevin Avatar asked Feb 23 '11 23:02

Kevin


1 Answers

About lockCanvas() from docs:

If you call this repeatedly when the Surface is not ready (before Callback.surfaceCreated or after Callback.surfaceDestroyed), your calls will be throttled to a slow rate in order to avoid consuming CPU.

Is it possible that your draw loop is initiated too early for some devices? I think this is the problem, since you wrote:

Now I discovered that if I add a delay in the constructor of my SurfaceView (of about 10 seconds), the slowness doesn't occur and all works fine.

like image 132
Simeon Avatar answered Oct 18 '22 15:10

Simeon