summaryrefslogtreecommitdiffstats
path: root/services/java/com/android/server/InputMethodManagerService.java
diff options
context:
space:
mode:
authorChet Haase <chet@google.com>2012-12-13 09:06:55 -0800
committerChet Haase <chet@google.com>2012-12-18 13:40:50 -0800
commitcc699b4fe396b3f93d45211d0df6f02baa325b2f (patch)
tree6521588f942059634a8f3ffc825ed96564f9b2df /services/java/com/android/server/InputMethodManagerService.java
parent412fbe7f8fb0fc2892308faf52c31dcc01e1cf5a (diff)
downloadframeworks_base-cc699b4fe396b3f93d45211d0df6f02baa325b2f.zip
frameworks_base-cc699b4fe396b3f93d45211d0df6f02baa325b2f.tar.gz
frameworks_base-cc699b4fe396b3f93d45211d0df6f02baa325b2f.tar.bz2
Fix for requestLayout-during-layout inefficiencies
An earlier fix made it possible to call requestLayout() during layout (which is not recommended in most cases outside of a ListView) without ending up with blank content and internal layout flags in a confused state. However, that fix incorrectly detected a problem in some cases (such as ListView practices of adding views during layout) which were actually okay; as long as you make sure to measure and layout your children properly before returning from layout(), then it's not a problem. We were improperly spamming the log with supposed problems, and causing more overhead in correct cases by running a full request/measure/layout pass after the first layout pass, all of which is unnecessary in cases where the containers know what they're doing. This new fix changes the logic to only cause the second layout pass (and third, posted to the next frame, if things are really done incorrectly) if the layout-request flags are still set on the requesting views after the full layout pass is complete. This situation causes the blank screens we've seen in buggy apps, and is exactly what we should avoid. However, correct cases (e.g., ListView) will not have these problems because they run measure/layout correctly after the request calls, which clears these flags. The upshot is that buggy cases will be detected and compensated for (by clearing the flags and then running a second request/measure/layout pass, as in the original fix) and non-buggy cases will be noop'd, going back to their previous, working logic flow. The bug below is one of the buggy apps to demonstrate this problem. I noticed that the original problem (blank screen) is no longer reproducible. I suspect that logic was added to the app to force a refresh after it is attached. You can still detect the problem (and the fix) by seeing that prior to the fix (say, on mr1.1) there is a delay of about a second between the end of the progress bar updates and the showing of content on a screen that used to just remain blank. With the fix (both the previous version and this one), the content is updated immediately, because we now handle the buggy request- during-layout situation in the same frame as it occurs. Issue #6914123 News and Weather app sometimes loads to a blank screen Change-Id: I4c34817cc3dd44ba422ff50de4321624c0824d83
Diffstat (limited to 'services/java/com/android/server/InputMethodManagerService.java')
0 files changed, 0 insertions, 0 deletions