Running out of ideas here :-) The test wasn't meant to see if Canvas would work or not. It was about the speed of the touch-event-message delivery. At least we figured out it isn't an issue with the onTouch callbacks. They happen fast enough.
What happens if you play with the values of the call to surfaceView.setEGLConfigChooser(8,8,8,8,8,8); Try 8, 8, 8, 8, 0, 0 (no depth, no stencil). Even try 5, 6, 5, 0, 0, 0 (RGB565, no depth, no stencil). The GLSurfaceView uses the swapBuffers command I have seen this being quite slow on some devices (admittedly, they all ran Cyanogen, no stock OSes). And on top of that, it is a locking call. On Thursday, August 1, 2013 5:30:57 AM UTC-4, Edvinas Kilbauskas wrote: > > OK, I did that. And yes. It doesn't have the delay anymore! But the > problem is... It's Canvas. I don't need canvas, it doesn't fulfill my > needs. I need OpenGL. > What the hell could be wrong? This is REALLY strange. OpenGL ES 1.0 has > delay, ES 1.1 has delay, ES 2.0 has delay. Canvas - no delay! > This should be other way around, because as far as I know canvas uses > software rendering, while OpenGL uses hardware, which should be way faster! > Any more ideas? > -- -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
