Re: [android-developers] invalidate() painting method
Hi Romain, If you don't mind, would you please describe how the implicit throttling mechanism works, or, point to any documentation on it? I think I am running into this, when my activities start, and the view is being invalidated often, it is throttled it seems for a little while (5-10 seconds?). After what seems to be an initial throttling, all is fine and I am seeing good frame rates. Some of my activities do a lot of of canvas drawing (using the HW accelerated rendering) triggered by sensor updates, and since JB I believe I've seen this throttling when the activity starts. I'd love to avoid this, while still getting 30fps+ when necessary. I could be wrong but it also seems the throttling is more prevalent/present if text is being drawn using canvas.drawText, but have not yet dug deeper into experimenting and figuring out how I can trigger or not trigger the throttling. Adam On Thursday, October 11, 2012 5:41:08 PM UTC-4, Romain Guy (Google) wrote: There is an implicit throttling mechanism as of 4.1 but even then it's bad. If you don't need to draw, don't draw. You're going to waste battery. On Thu, Oct 11, 2012 at 2:34 PM, bob b...@coolfone.comze.comjavascript: wrote: As you may know, you can create a View subclass and then call invalidate() at the end of the painting method. This produces continuous updating. Is this really really bad? It sure is attractive due to its simplicity. However, there is no explicit throttling mechanism, which can be an issue if there is also no implicit one. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-d...@googlegroups.comjavascript: To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Romain Guy Android framework engineer roma...@android.com javascript: -- 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
Re: [android-developers] invalidate() painting method
The throttling is simply a side effect of v-sync. Every paint request is synced with the display's refresh rate. This means you can only draw every ~16 milliseconds (== 60 fps.) Of course, if your application cannot draw in 16 ms you will be synced every 2 frames and you will fall to 30 fps. On Sun, Oct 14, 2012 at 2:08 PM, Adam Ratana adam.rat...@gmail.com wrote: Hi Romain, If you don't mind, would you please describe how the implicit throttling mechanism works, or, point to any documentation on it? I think I am running into this, when my activities start, and the view is being invalidated often, it is throttled it seems for a little while (5-10 seconds?). After what seems to be an initial throttling, all is fine and I am seeing good frame rates. Some of my activities do a lot of of canvas drawing (using the HW accelerated rendering) triggered by sensor updates, and since JB I believe I've seen this throttling when the activity starts. I'd love to avoid this, while still getting 30fps+ when necessary. I could be wrong but it also seems the throttling is more prevalent/present if text is being drawn using canvas.drawText, but have not yet dug deeper into experimenting and figuring out how I can trigger or not trigger the throttling. Adam On Thursday, October 11, 2012 5:41:08 PM UTC-4, Romain Guy (Google) wrote: There is an implicit throttling mechanism as of 4.1 but even then it's bad. If you don't need to draw, don't draw. You're going to waste battery. On Thu, Oct 11, 2012 at 2:34 PM, bob b...@coolfone.comze.com wrote: As you may know, you can create a View subclass and then call invalidate() at the end of the painting method. This produces continuous updating. Is this really really bad? It sure is attractive due to its simplicity. However, there is no explicit throttling mechanism, which can be an issue if there is also no implicit one. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-d...@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 -- Romain Guy Android framework engineer roma...@android.com -- 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 -- Romain Guy Android framework engineer romain...@android.com -- 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
Re: [android-developers] invalidate() painting method
Thank you for the response! I should also say that this only occurs upon creation of the activities, and not when they resume or at any point thereafter. The only thing in common that the various activities have is that they use canvas drawing calls (and draw text), some are not even timed based on the sensors, but triggered from other ui events (slider). Is there anything that could be happening upon creation that could cause this? I don't think this is the vsync throttling, in fact things are performing better on JB than on ICS all things equal, other than this initial slowness, and certainly better than 30fps. Is there anything you can suggest perhaps looking for in a traceview? On Sun, Oct 14, 2012 at 6:51 PM, Romain Guy romain...@android.com wrote: The throttling is simply a side effect of v-sync. Every paint request is synced with the display's refresh rate. This means you can only draw every ~16 milliseconds (== 60 fps.) Of course, if your application cannot draw in 16 ms you will be synced every 2 frames and you will fall to 30 fps. On Sun, Oct 14, 2012 at 2:08 PM, Adam Ratana adam.rat...@gmail.com wrote: Hi Romain, If you don't mind, would you please describe how the implicit throttling mechanism works, or, point to any documentation on it? I think I am running into this, when my activities start, and the view is being invalidated often, it is throttled it seems for a little while (5-10 seconds?). After what seems to be an initial throttling, all is fine and I am seeing good frame rates. Some of my activities do a lot of of canvas drawing (using the HW accelerated rendering) triggered by sensor updates, and since JB I believe I've seen this throttling when the activity starts. I'd love to avoid this, while still getting 30fps+ when necessary. I could be wrong but it also seems the throttling is more prevalent/present if text is being drawn using canvas.drawText, but have not yet dug deeper into experimenting and figuring out how I can trigger or not trigger the throttling. Adam On Thursday, October 11, 2012 5:41:08 PM UTC-4, Romain Guy (Google) wrote: There is an implicit throttling mechanism as of 4.1 but even then it's bad. If you don't need to draw, don't draw. You're going to waste battery. On Thu, Oct 11, 2012 at 2:34 PM, bob b...@coolfone.comze.com wrote: As you may know, you can create a View subclass and then call invalidate() at the end of the painting method. This produces continuous updating. Is this really really bad? It sure is attractive due to its simplicity. However, there is no explicit throttling mechanism, which can be an issue if there is also no implicit one. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-d...@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 -- Romain Guy Android framework engineer roma...@android.com -- 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 -- Romain Guy Android framework engineer romain...@android.com -- 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 -- Adam Ratana adam.rat...@gmail.com -- 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
[android-developers] invalidate() painting method
As you may know, you can create a View subclass and then call invalidate() at the end of the painting method. This produces continuous updating. Is this *really really* bad? It sure is attractive due to its simplicity. However, there is no explicit throttling mechanism, which can be an issue if there is also no implicit one. -- 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
Re: [android-developers] invalidate() painting method
There is an implicit throttling mechanism as of 4.1 but even then it's bad. If you don't need to draw, don't draw. You're going to waste battery. On Thu, Oct 11, 2012 at 2:34 PM, bob b...@coolfone.comze.com wrote: As you may know, you can create a View subclass and then call invalidate() at the end of the painting method. This produces continuous updating. Is this really really bad? It sure is attractive due to its simplicity. However, there is no explicit throttling mechanism, which can be an issue if there is also no implicit one. -- 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 -- Romain Guy Android framework engineer romain...@android.com -- 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
