Are you using TextureView? Do you see the same issue with a GLSurfaceView? You could also try using http://developer.android.com/tools/debugging/systrace.html to see if anything strange is going on in the system when you drop frames. OpenGL-wise it looks pretty simple.
Tobias Den tisdagen den 15:e april 2014 kl. 06:00:24 UTC+2 skrev Dave Smith: > > Thanks for the response, Doug, but we're talking about two different > things. I'm not referring to the errors that show up the log tagged > Choreographer when the frame warning limit is triggered on the main thread. > I'm talking about actually using the Choreographer API to render OpenGL > content locked to VSYNC. These delays are on the rendering threads. While > I understand frames dropping periodically when the system is servicing > other work, the inability to manage even a few second without skipping > several VSYNC intervals indicates to me that something else is wrong with > the GL code. > > Thanks again, > Dave Smith, PE > Double Encore, Inc. > > On Sunday, April 13, 2014 12:51:07 PM UTC-6, Doug wrote: >> >> Bear in mind that anything could be causing main thread delays. It could >> be your code. It could be other threads in your app's process. It could >> be other apps running on the device. It could be Android itself. It could >> be any combination of these things. This is to be expected with >> multitasking multiuser operating systems and the wide variety of devices >> out there and their hardware capabilities. >> >> The Choreographer itself doesn't start complaining about skipped frames >> in logcat until after 30 frames have been skipped: >> >> private static final int SKIPPED_FRAME_WARNING_LIMIT = >> SystemProperties.getInt( >> "debug.choreographer.skipwarning", 30); >> >> So maybe you can lighten up your own acceptable threshold for frames >> skipped (unless you're actually observing the jank that you're trying to >> avoid)? >> >> Doug >> >> On Friday, April 11, 2014 10:37:39 AM UTC-7, Dave Smith wrote: >>> >>> Hello all - >>> >>> I am working on an application that is using Choreographer and OpenGL to >>> render flash patterns on the display. Our GL calls are quite simple, >>> simply toggling the display back and forth between white and black using >>> glClearColor() based on the frame time and status of the pattern we want to >>> apply. The timing of this pattern if very critical, and I am having severe >>> issues getting consistent behavior out of the timing pulses we received >>> from Choreographer to do the rendering. >>> >>> For simplicity sake, I have basically copied the Basic Dream application >>> in AOSP, so 95% of my code looks exactly like this sample: >>> >>> https://android.googlesource.com/platform/packages/screensavers/Basic/+/master >>> >>> Our only change is that, where they call mSquare.draw() inside of >>> doFrame(), we have another method called drawFrame() that does the >>> following: >>> >>> private void drawFrame() { >>> final boolean nextBit = mPattern[mIndex]; >>> >>> if (nextBit) { >>> glClearColor(1.0f, 1.0f, 1.0f, 1.0f); >>> } else { >>> glClearColor(0.0f, 0.0f, 0.0f, 1.0f); >>> } >>> glClear(GL_COLOR_BUFFER_BIT); >>> >>> return true; >>> } >>> >>> However, for the purposes of this discussion, you can see the *exact >>> same behavior* by simply running the AOSP sample as an application >>> (i.e. changing the Colors class from a DreamService to a launcher Activity). >>> >>> The problem is that on a regular basis (at least once per second, often >>> many times), the debug logging returns that the frame callback took 33ms >>> (instead of 16ms), and in many cases 50ms+! I can understand skipping a >>> rare frame here or there, but skipping 3-4 frames at once seems like I'm >>> missing something big here. Not all devices do this, but high-end devices >>> like the Nexus 5 and GS4 do. Devices we've tested like the Note 3, GS3, >>> and Moto X don't seem to do so nearly as often. Example typical logcat >>> over a period of 30 seconds: >>> >>> 04-11 11:35:43.918 10441-10455/com.android.dreams.basicgl >>> V/ColorsGLRenderer﹕ JANK! (49865722 ms) frame 2 >>> 04-11 11:35:43.948 10441-10455/com.android.dreams.basicgl >>> V/ColorsGLRenderer﹕ JANK! (33264161 ms) frame 3 >>> 04-11 11:35:43.988 10441-10455/com.android.dreams.basicgl >>> V/ColorsGLRenderer﹕ JANK! (33233641 ms) frame 4 >>> 04-11 11:35:44.018 10441-10455/com.android.dreams.basicgl >>> V/ColorsGLRenderer﹕ JANK! (33233644 ms) frame 5 >>> 04-11 11:35:45.860 10441-10455/com.android.dreams.basicgl >>> V/ColorsGLRenderer﹕ JANK! (33264161 ms) frame 115 >>> 04-11 11:35:46.881 10441-10455/com.android.dreams.basicgl >>> V/ColorsGLRenderer﹕ JANK! (33233641 ms) frame 175 >>> 04-11 11:35:47.692 10441-10455/com.android.dreams.basicgl >>> V/ColorsGLRenderer﹕ JANK! (33233642 ms) frame 222 >>> 04-11 11:35:48.242 10441-10455/com.android.dreams.basicgl >>> V/ColorsGLRenderer﹕ JANK! (33264160 ms) frame 255 >>> 04-11 11:35:49.373 10441-10455/com.android.dreams.basicgl >>> V/ColorsGLRenderer﹕ JANK! (33233643 ms) frame 322 >>> 04-11 11:35:53.908 10441-10455/com.android.dreams.basicgl >>> V/ColorsGLRenderer﹕ JANK! (33268229 ms) frame 594 >>> 04-11 11:35:56.190 10441-10455/com.android.dreams.basicgl >>> V/ColorsGLRenderer﹕ JANK! (33264161 ms) frame 730 >>> 04-11 11:35:56.690 10441-10455/com.android.dreams.basicgl >>> V/ColorsGLRenderer﹕ JANK! (33233643 ms) frame 759 >>> 04-11 11:35:57.751 10441-10455/com.android.dreams.basicgl >>> V/ColorsGLRenderer﹕ JANK! (49965416 ms) frame 821 >>> 04-11 11:35:57.781 10441-10455/com.android.dreams.basicgl >>> V/ColorsGLRenderer﹕ JANK! (33164467 ms) frame 822 >>> 04-11 11:35:58.952 10441-10455/com.android.dreams.basicgl >>> V/ColorsGLRenderer﹕ JANK! (33233643 ms) frame 891 >>> 04-11 11:36:04.678 10441-10455/com.android.dreams.basicgl >>> V/ColorsGLRenderer﹕ JANK! (33264161 ms) frame 1235 >>> 04-11 11:36:05.919 10441-10455/com.android.dreams.basicgl >>> V/ColorsGLRenderer﹕ JANK! (33264159 ms) frame 1308 >>> 04-11 11:36:07.781 10441-10455/com.android.dreams.basicgl >>> V/ColorsGLRenderer﹕ JANK! (33298746 ms) frame 1419 >>> 04-11 11:36:07.821 10441-10455/com.android.dreams.basicgl >>> V/ColorsGLRenderer﹕ JANK! (49800618 ms) frame 1420 >>> 04-11 11:36:08.672 10441-10455/com.android.dreams.basicgl >>> V/ColorsGLRenderer﹕ JANK! (33325196 ms) frame 1470 >>> 04-11 11:36:11.955 10441-10455/com.android.dreams.basicgl >>> V/ColorsGLRenderer﹕ JANK! (33264160 ms) frame 1666 >>> 04-11 11:36:13.687 10441-10455/com.android.dreams.basicgl >>> V/ColorsGLRenderer﹕ JANK! (33264159 ms) frame 1770 >>> >>> Any help from the OpenGL experts in the room is greatly appreciated! Is >>> there something the sample is doing poorly that I just unknowingly copied >>> into my own code? >>> >> -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
