How to use canvas instead of OpenGL

Monkey Targets Forums/Android/How to use canvas instead of OpenGL

Xaron(Posted 2011) [#1]
Hi all (especially Mark),

is there a way to use the old canvas style for drawing instead of OpenGL. I have the impression that a lot of these image draw stuttering comes from the OpenGL part.


benmc(Posted 2011) [#2]
From my experience, canvas is super slow, but works just fine for a lot of simple games.

I hope he finds a way to nix the stuttering altogether on Android and keep the OpenGL. Lots of games use it, there must be a trick or something.

I need the power of OpenGL for the game I'm writing now, and I'm avoiding the stuttering problem by drawing every single thing off-screen during a loading process. Still it's only kind-of working unfortunately.

Hoping someone smarter than me knows a tweak that can be made to the mojo module or something again.


Xaron(Posted 2011) [#3]
benmc I do this offscreen painting as well but this doesn't work on all devices as I've found out today. Especially when you have a lot of graphics I guess the "oldest" ones are dropped out of the cache again. Well ok I might have to implement some more intelligent caching...

Actually Android is a horror to develop for, Windows 7 Phone and iPhone are so much easier and straight forward to use without these hacks...


anawiki(Posted 2011) [#4]
Yes, as a programmer I am shocked that people like Android devices. They are sooo bad compared to iOS devices. I start to wonder if the only reason people like Android devices is the fact that they can easily pirate software.


benmc(Posted 2011) [#5]
I agree, I am coming across so many problems with Android, and it's getting more and more frustrating.

I was able to solve the problem of black/pixel lines showing up to the right of my images, but now I'm getting lines on the BOTTOM of the images that I can't figure out how to get rid of - even with pixel padding.

Then, I am now experiencing what you are Xaron - it seems to "forget" some graphics now that I have a lot to draw. I'm not sure if I can change something or not regarding how much is cached and for how long.

Everything works flawlessly on iOS, GLFW, and Flash. Android is so frustrating.

Maybe the OP is right, maybe having an option to use the Canvas would help in some ways. My struggles with Canvas with my pure Java games has been frame rates slowing way down at times, then speeding back up. Very frustrating.


MikeHart(Posted 2011) [#6]
If oyu avoid dynamic object creation on Android as much as possible, but Monkey still does it under the hood, then there is nothing we can do. The stuttering comes form the GC. The more dynamic objects are created and released, the more it will affect the game.


AdamRedwoods(Posted 2011) [#7]
Then, I am now experiencing what you are Xaron - it seems to "forget" some graphics now that I have a lot to draw. I'm not sure if I can change something or not regarding how much is cached and for how long.


I wonder if you're running into texture limits, which are around 24mb for phones.
If you're testing on PowerVR devices, you could try using some of their profiling tools:
http://www.imgtec.com/powervr/insider/powervr-utilities.asp


Monkey isn't doing a whole lot of dynamic object creation behind the scenes, except when loading images. Also note that monkey on android has no hidden GC, it's straight-up java managed GC.

Also note monkey may not be the problem:
http://groups.google.com/group/android-developers/browse_thread/thread/2de64b6ebb98129/eede34e343485313?lnk=gst&q=stuttering#eede34e343485313

Read the bottom note, it says to add gl.glFinish() to your games:
http://stackoverflow.com/questions/3706786/htc-desire-specific-opengl-es-1-frame-rate-cant-get-it-right


Pudsy(Posted 2011) [#8]
Some method to toggle the "canvas" rendering would DEFINITELY get my vote! :)
Or even better, automatically fall-back to it if the current device doesn't support GL properly?

Ever since Monkey v44 (I believe this is where the change was made) I've been getting all kinds of graphical anomalies, and only on Android... it all works great on every other target!

All the graphical issues have been discussed in other threads & some are mentioned above... lines on edges of images, completely garbled images, images being swapped around, etc.

Some of those problems only manifest themselves on certain devices (including various Samsung models, and an HTC in my experience so far). But eg. the lines on image edges seemingly affects every device including the emulator.

If I build with Monkey v43, although rendering is a little slower, pretty much all of the glitches go away on every device I've tested.


benmc(Posted 2011) [#9]
@AdamRedwoods To experiment, I put:

gl.glFinish();

into the function:

public void onDrawFrame( GL10 gl )

in the Android mojo native java file, and I think the "stuttering" problem I was having on Android has gone away.

However, I wouldn't recommend anyone do this because I have no idea what I've done. Do you or Mark know what's actually happening by doing this? I'm personally worried that I've opened a bigger can of worms and haven't fixed anything. I don't know if the app now uses a lot of extra memory, or creates other problems, but in my case, I *think* I'm seeing some improvements in how smoothly my game runs at 45fps on Android by adding that line.

Any thoughts?


AdamRedwoods(Posted 2011) [#10]
Interesting, but it goes along with other findings in that link I posted above.

glFinish() waits for the graphics chip to finish before returning to the current process. I feel it's harmless and if anything would create lag. I'll have to try it on some devices.


The android system (GLSurfaceView) is suppose to take care of this, and it may, but it seems there may be something hidden going on beneath the Android layers.

OTHER THOUGHTS:
i wonder if opengl is storing texture calls, so I wonder if it will work just as well putting it at the end of gxtkSurface.Bind() instead. If you move it there and stuttering still goes away then it's the processor storing texture calls that causes the stutter.

If it doesn't then it may just be the processor storing graphics commands.