The calculateLocalPaths() method of UsageGraph converts a set of paths
in (milliseconds, percent) coordinates into the actual pixel values that
will be used for drawing. For the most part this is a one to one
process, but not always: input points that are too closely spaced to
draw accurately are skipped. The last point in the path, however, is
never skipped, in order to ensure that the graph ends at the correct
location.
The previous implementation of this method had a bug: the y-coordinates
of points that were skipped would be stored indefinitely (in the local
variable pendingYLoc) and then added back at the very end of the path
(under the condition i == mPaths.size() - 1 && pendingYLoc !=
PATH_DELIM). Under the right conditions, this led to the strange uptick
at the end of the graph seen in the associated bug.
This CL fixes the problem and attempts to make the logic slightly
clearer. It also adds tests, one of which (_similarPointMiddle) fails
for the previous code.
In more detail, previously pendingXLoc was used to hold the last x
coordinate seen, while pendingYLoc was used to hold the last *skipped* y
coordinate, or PATH_DELIM otherwise. The difference between these was
somewhat subtle and hard to understand from a quick read of the code,
and there was a bug: pendingYLoc never got reset to PATH_DELIM even if
later points were added. In this CL I have removed the pendingLoc
variables in favor of a single lx/ly pair, which always holds the local
coordinates of the most recent point, and I added an explicit boolean
skippedLastPoint to track whether the point (lx, ly) has already been
added or was skipped.
Bug: 64065296
Test: make RunSettingsRoboTests
Change-Id: I45ccffea1280d851bfae5143c2e84d188e133731
This CL adds logging to areas which are possible suspects for
the slowdown some people have been reporting in the
PowerUsageAdvanced screen. It times the time it takes for various
battery stats methods as well as the time it takes to draw things.
Test: still build (only adds logging)
Bug: 62959645
Bug: 63442960
Change-Id: I7e6c5e83e33a931057c9fdef14d3bef84f514940
BatteryInfo now supplies standard linear or enhanced projection curves,
depending on the provider.
Note that the semantics of parsing have changed slightly in that the
value of endTime supplied to onParsingStarted is now the end time of the
historical data and does not include the projection. However, as far as
I can see there is no existing code that depends on the parsing
functionality besides BatteryInfo itself.
Also slightly optimizes the updating behavior of the UsageGraph, since
we are now reconfiguring it multiple times.
Bug: 38400320
Test: make RunSettingsRoboTests, manual on device
Change-Id: Ieff26d31356b34bb38e49f54f979fd80549864b2
Previously, projections were hard-coded in UsageGraph as lines from the
last known point to the corner of the graph. This change replaces that
with support for arbitrary projection curves. Logic for hiding/showing
the projection is now gone; if the client does not want a projection,
it simply does not supply one.
There are two active clients of this code: the data usage graph and the
battery usage graph. The data graph does not use projections and is
essentially unchanged. The battery graph now implements its linear
extrapolation directly in BatteryInfo.
Bug: 38400320
Test: make SettingsUnitTests SettingsGoogleUnitTests
Test: manual (screenshots in comments)
Change-Id: I754e66f6b18ecb8b936143399f8e9e3368fc1ce4
In preparation for modifying the graph code to show detailed projections
(see bug), this change moves it into Settings along with related tests
and resources.
Bug: 38400320
Test: manual, make SettingsUnitTests, make SettingsGoogleUnitTests
Change-Id: I88e5336c15827727b3427e29b10954bba9cfba7d
