We changed this MeanDepthLine to the MeanDepthCurve (or something),
no need to keep old code around.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This ruler shouldn't appear in ADD or PLAN mode, it's a bug
and may crash things.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
the manual uses "Sensor 1:", not sure if it breaks anything.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Mean depth/s sounds too much like a rate of change but this
referers to instantaneus mean depth at a time.
Signed-off-by: Tim Wootton <tim@tee-jay.demon.co.uk>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This patch takes the cylinder pressures of CCR dives and prints them
in a non-overlapping way.
Remaining issue: When the dive profile is made taller by dragging the
window or the appropriate slider far down the screen, the labels move
further apart; similarly, when the profle is made flat/shallow by dragging
the window edge or appropriate slider up, the labels get close to each
other and start to overlap.
There are quite a few lines of additional code going into the patch. This
is primarily because separate provisions for when po2 > p(diluent) or vice
versa. In addition, I could not determine the size of the text characters
which would allow much more precise placement of text. This is because the
.scale member of the text is private and not available in the methods
involved in printing the labels. However, the height of the vertical scale
of the cylinder pressure graph can be determined [e.g. vAxis->maximum()].
This helped a lot to get the positioning of the text more or less correct.
While the results of the patch is not perfect, It contributes
significantly to make the profiles of Poseidon dives more readable.
Signed-off-by: willem ferguson <willemferguson@zoology.up.ac.za>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When calculating maxima for a dive, we need to take data from all existing
dive computer structures plus potentially also a fake dive computer
structure that is just passed in in order to create a meaningful profile.
Commit 86c961614b ("Actually walk all dive computers, don't just claim
to do so") missed that second case and no longer took the fake_dc into
account, breaking the display of dives that don't have samples.
Reported-by: Miika Turkia <miika.turkia@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
There were situations when the last text was still shown. E.g. when the
current file was closed and then a new dive was imported from CSV.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This patch does some cleaning up of the code that provides visualisation
of CCR o2 sensor and o2 setpoint data. It reduces the number of
conditional evalauations that are required and it improves the readability
of these parts of the code.
Signed-off-by: willem ferguson <willemferguson@zoology.up.ac.za>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This patch creates the possibility of viewing the individual sensor
values when the po2 button on the profile toolbar is activated. This
follows exactly the procedure for optionally displaying the setpoint
values while viewing po2. A checkbox in the preferences panel determines
whether sensor information is shown. By default it is set to OFF. When
checked, and the po2 button is activated, sensor1 values are shown in
grey, sensor2 in blue and sensor3 in brown.
Signed-off-by: willem ferguson <willemferguson@zoology.up.ac.za>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If the first dive computer had pressure samples, but the second one (and
no higher one) did, then we would draw a flat horizontal line for the tank
pressure graph (but lable it with the correct pressures). This routine
that is hunting for the actual maxima and minima does have to really go
through all dive computers, not just "this one and up".
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Whoa, this deserves a good explanation.
Everytime that the mouse moved in add / plan mode, or anytime a new dive
was displayed on the profile, this method would be called and connect the
dataModel to the modelChanged method. This added the slot in a call-vector
that the fired signal would call, adding one call to the Slot per add /
plan mouse move (about 20x/s) or each time a new dive was displayed.
Quickly filling the vector with more than 200 - 300 calls to this same
Slot.
The fix is to only connect one time. this made the add / plan mode *so*
much smoother... :)
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
qt-ui/profile/profilewidget2.cpp:1351:10: error: invalid use of incomplete type ‘class QDebug’
qt-ui/printlayout.cpp:141:27: error: variable ‘QPointer<ProfileWidget2> profile’ has initializer but incomplete type
In commit f9ceff009b ("Clean up the header files") things got broken for
an as of now unreliesed future version of Qt.
Signed-off-by: Thiago Macieira <thiago@macieira.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Move the heart rate graph down to the same space as the tissue saturation
graph so that it does not overlap with temperature or partial pressures.
Signed-off-by: Joakim Bygdell <j.bygdell@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Lots and lots and lots of header files were being included without being
needed. This attempts to clean some of that crud up.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This cache give us a huge gain in performance, going from
17% moving the mouse frenetically to 9%, wich is quite acceptable.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We used to create a new QGraphicsRectItem everytime a Pixmap
changed. Since I'm pretty sure I deleted every bit of the
PictureItem before setting a new one, no leak was due, but this
version is safer.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We were calling this even if we didn't really change anything
and paths are expensive to paint.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We were recreating the PathItems (one for the outline, other for the real
text) for every call to setText. This was a very un-smart move.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This reduces a lot of CPU time and makes the overall use of the tooltip a
breeze.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The tooltip animation had a fixed animation speed, this patch
honors the anim_speed on the preferences, and also disables
the animation completely if the speed == 0.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
There are a few calculations that go on boundingRect that can be avoided
if we simply store the result.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Correct pen and brush set. the ToolTip now is correctly rounded,
translucent and happy.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The rectangle is now correct, but the collors are still
wrong. I'm tracking that down - most probably I've set
the wrong pen or brush ( or both ) somewhere.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Those items were used to fake the background of the path item
but since the rectangle can be painted with a border and a
fill, this is uneeded.
The rect is still ugly.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
a rectangle is *much* faster to paint than a simple ShapeItem,
so this is a safer choice. We still need to create the paint
method so we can use the correct roundness for the rectangle.
Currently it's white with a 1px solid line - terrible. :)
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We were deleting / recreating the graphics background item for *every*
mouse movement. Now we are just creating the painter path; no more
allocations / desalocations, adding, removing from the scene. This should
make things a tiny bit faster.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
While analizing the code for the mouse movement I've discovered that
we did a lot of uneeded things: Set the color, the pen, the size
of a fixed-colored line, twice.
We also deleted-newed the same Pixmap / Text for every mouse movement
so now we reuse the 'entryToolTip' that consists of a huge line and
a pixmap, and after that we add the other tooltips that are not static
Also, reduced a lot the number of calls to expand() (that did a lot of
math).
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Strangelly, this method was being called even if the rectangle was the
same, so we deleted everything and recreated everything again. tsc tsc.
Some more improvement is needed but we are getting there.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Very often the rectangle of the ToolTip doesn't need to change but we were
calling and firing an animation for it for *every* mouse movement, even
when we didn't really needed it.
Now it will only fire something if the rectangles are indeed different.
From my tests we reduced the number of calls to the animatior by about 20%
using a real divelog as test.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is an attempt to make fewer calls to alloc functions when the mouse
is moving.
We were creating a membuffer, filling it (malloc / realloc), then freeing
it just after use. but we could simply hold that allocated area and reuse
it again.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We did three cals to mapToScene / mapFromScene on the mouse moveEvent at
the ProfileWidget2 where we only needed to call one in the common case and
two in the worst case.
This doesn't really help in terms of speed (unless you have a really old
cpu) but since it's code that gets called *very* often, it seemed a
reasonable thing to do.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The QPainter and the QPixmap were being created but never freed. A QPixmap
and a QPainter don't need to be created by new, they can be safely created
on the stack.
So, create them on the stack, pass them via const-reference
and use them correctly.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
After looking with great care at the result of the mouse movement
on the profile, and also playing a bit with callgrind I've found
out that one thing that we were doing wrong was the way we looked at the
items in the scene, by calling scene()->items with
Qt::ItemIntersectsShape, our shapes are very complex curves
with thousends of points and we have lots of them. and it usually
doesn't matter because *most* of the time we are getting the
tooltip information from 'get_plot_details_new', so no accessing
to items was necessary.
By changing the access from Qt::ItemIntersectsShape to
Qt::IntersectsItemBoundingRect we had a speedup of almost 500x in a
section of code that's very important, and the good thing, nothing bad
happened because one of the only things that we are using this code is to
get information from the events, not the curves.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Take instantMeanDepthLine out of the code. We have the moving average line
plus the exact data in the information overlay.
Signed-off-by: Cristine Guadelupe <cristineguadelupe@me.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Correct minor malfunction with CCR setpoint display. It was showing even
when the po2 display was turned off. This patch ensures that the setpoint
graph only shows when the po2 toolbar button is activated (and in addition
the appropriate checkbox in the Preferences).
Signed-off-by: willem ferguson <willemferguson@zoology.up.ac.za>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Commits 0de3bc8452 ("Display CCR setpoint values on the po2 graph") and
65eed80e37 ("Don't always show the setpoint graph") didn't take into
account that current_dive could be NULL and therefore accessing current_dc
could crash.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Oxygen should be representad by its own solid green colour not the yellow/green of nitrox.
Signed-off-by: Joakim Bygdell <j.bygdell@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When a CCR dive is viewed and the toolbar button for PO2 is activated,
both the PO2 (green line) and the O2 setpoint (red line) are shown.
This allows evaluation of the PO2 in the CCR loop with respect to the
pre-configured O2 setpoint.
The setpoint graph can be disabled from the Preferences/Graphs tab
by checking the appropriate checkbox.
Signed-off-by: willem ferguson <willemferguson@zoology.up.ac.za>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Fix various discrepancies in the capitalization format, as we are using
'down format' for titles and actions.
Signed-off-by: Joseph W. Joshua <joejoshw@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
A value of zero (which is the normal legacy one) remains "unknown", but
the divecomputer backend can now give both gasmix and cylinder number
this way.
Currently only the EON Steel backend does that, but it should be easy
enough to extend others too.
Also, fix the user-visible cylinder numbering in the cylinder change
tooltip to use a human-friendlier one-based numbering (ie first cylinder
is "cyl 1", not "cyl 0")
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The code tried to look up the cylinder index from the Qt data models,
which was not only horribly confusing, but was also buggy. I think the
index ends up being off by one when the first cylinder change is hidden
(because it's at the beginning of the dive), but I can't make heads or
tails of that crazy code, so there might be something else going on.
Just remove all the crazy code, and use the event data directly. Which
gas the gasmix and the (potential) explicit cylinder index already.
It's much more straightforward, and it just automatically gets the right
end result whether some other event is hidden or not.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
