.. go back to more GC-like color defaults, which became a little
too vibrant in a recent update to introduce linear gradients to
the CP, Histogram and LTM plots.
- none - no shading on the all curve
- derived CP - as before using the CP value derived from all curve data
- CP - the value of CP for the time of the ride
NOTE: When in rangemode (i.e. on home) the CP is set to the mean CP for
the date range selected.
.. kept allocating a new RideFileCache but didn't delete
the previous one. Given their relatively large size this
can lead large amounts of memory lost in a short amount
of time.
My eyes started to bleed at the burst of color
on the cp plot after the introduction of a
linear gradient there. Just toned it down a bit
for the "rainbow" all curve.
Last part of the search/filter functionality;
* SearchBox now incorporates filter and search
with a new widget. We can update this widget
to include more fancy UI/Interactions without
having to change the ride list or charts etc.
* Added search/filter widget to the relevant charts
and screens; Metrics, TreeMap, CP, Histogram,
Activity Log, Ride list (refactored out of MainWindow)
* Added namedsearches.xml and adding/selecting them
from a drop down menu on the search box.
* Fixed some performance bugs related to duplicate
signals and redraw/reprocessing. Also ensured that
CLucene remains optional -- but means no search or
filter functionality unless it is available.
Upgrade to QWT 6.0.1, but still uses a locally patched copy
since support for 8 axes has not been included, despite it
being a relatively simple patch.
Fixes#634.
Fixes#567.
Very basic start, this will now let you plot
VAM on the CP curve. VAM is a measure of climbing
speed and for comparative purposes should be
normalised to the slope climbed.
In this first pass of implementation the VAM metric
is not normalised in any way. It merely represents
the climbing rate, in meters per hour, that was
sustained over each time interval from 5mins to the
ride duration.
If the ride is undulating then only ascension is
included, any time on the flat or descending is
included but meters climbed will be zero. This is
akin to the way we handle power where we include time
when freewheeling.
More sophistication is needed, especially normalising
the value to a common gradient (e.g. 10%). But this
will prove challenging when VAM is comprised of
undulating elements (i.e. gradient is cumulatively
zero, but could contain segments with steep parts).
It may be more appropriate to only measure VAM for
sustained climbing i.e. ignore ride sections when
descending or on the flat.
More thought needed.
Fixes#414.
Added a dropshadow effect for window tiles and made the
title embossed for a more professional look.
Also fixed a couple more compile time nits introduced
by recent commits.
An update to the ride list on the left hand side
to enable the user to choose and sort or group-by
metrics, metadata fields and ride information.
In addition, the sidebar has been 'improved'
cosmetically and to require less screen estate.
Also, the ticks and frames on plots have been
adjusted to be more aesthtically appealling.
There is more to come on the look-and-feel front,
but this patch heralds some work on the sidebar
which needs to be resolved.
Mark Rages has developed a super fast and innovative
approach to identifying max-mean intervals. This
approach is 20% faster than the current approach and
importantly does not require "downsampling" of data
yielding much higher resolution for longer intervals.
The code has not been 'adjusted' to adopt QT style
containers (e.g. QVector) and uses malloc/free.
The primary innovations include:
* integrating the data series to reduce the operation
for identifying an interval sum to a single subtract
operation.
* Searching for max sum via a window-search rather
than iterating over the entire series (divide / conquer)
Interestingly, now we have retained high resolution the
xPower algorithm still yields differing results to the
existing metric code. I have contacted Sean to get some
insight into why this might be the case, but suspect it
is related to the implementation of the xPower 25s EWMA.
Tip o' the hat to Mark Rages for this -- sometimes you
just have to accept that no matter how smart you think
you are, there are some folk who /really are/ smart!
A tooltip is now shown on the CP chart if you move
the cursor over a point in the chart. The old picker
ribbon is still shown when using left-click with
the dates and values shown in the controls.
The Skiba and Coggan metrics for xPower and NP
respectively can now be plotted on the CP curve.
There are two issues;
* Downsampling of data to 5s samples skews xPower's EWMA
* Setting scale to start at 30mins breaks the x-axis scale engine
Both issues need fixing, since the first skews xPower upwards and
the second suggests that xPower/NP are meaningful for durations
less than 30 minutes.
Fixes#307.
This patch enables more data series to be plotted on a CP plot.
We can now show curves for heartrate, cadence, speed and torque
as well as the original power and energy.
The CP code is refactored into the plotting functions and a new
RideFileCache that precomputes the mean-max as well as distribution
data (for a later patch to show histograms across date ranges).
The code for computing mean-max values has been re-written and
significantly optimised by;
* computing 1s intervals up to 5mins only
* computing 20s intervals for the remainder of the ride
* downsampling data to 5s samples for longer durations
* using a binary file format (cpx) for faster read/aggregation
* using multiple threads
Testing on an old Athlon dual-core showed an increase in performance
over the old cpi code of approximately x20, but since new data series
are now computed it is only x4 faster. Quad/Octo core systems will
show a greater performance increase though.
A new config pane for defining color preferences for chart
curves, shading, background and grid lines et al. Default values
echo the current hard-coded values.
RideItem or RideFile or dataPoints() may be null or empty. This
is especially true of manual ridefiles. This patch adds some
checks for this situation and acts accordingly. Additionally, the
disable/enable of tabs depending upon ridefile type has been
adjusted to also include files with not dataPoints.
This mode is fun because the "CP Curve" is a straight line,
just like in the model:
work = CP * time + AWC
You can also see that the AWC is the y-intercept.
Anchoring this regexp (i.e., making it start with a "^") reduces the time
it takes to load the first CP plot from 10 seconds to 6.5 seconds on
Sean's three years of rides. Unbelievable, but repeatable.
