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 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/d/optout.
