2011-08-31 17:20:46 +00:00
|
|
|
#include <stdio.h>
|
|
|
|
#include <stdlib.h>
|
2011-09-06 17:25:01 +00:00
|
|
|
#include <stdarg.h>
|
2011-09-08 15:33:02 +00:00
|
|
|
#include <string.h>
|
2011-08-31 17:20:46 +00:00
|
|
|
#include <time.h>
|
|
|
|
|
|
|
|
#include "dive.h"
|
|
|
|
#include "display.h"
|
2011-09-05 19:12:58 +00:00
|
|
|
#include "divelist.h"
|
2011-08-31 17:20:46 +00:00
|
|
|
|
2011-08-31 18:07:31 +00:00
|
|
|
int selected_dive = 0;
|
|
|
|
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
/*
|
|
|
|
* Cairo scaling really is horribly horribly mis-designed.
|
|
|
|
*
|
|
|
|
* Which is sad, because I really like Cairo otherwise. But
|
|
|
|
* the fact that the line width is scaled with the same scale
|
|
|
|
* as the coordinate system is a f*&%ing disaster. So we
|
|
|
|
* can't use it, and instead have this butt-ugly wrapper thing..
|
|
|
|
*/
|
|
|
|
struct graphics_context {
|
|
|
|
cairo_t *cr;
|
|
|
|
double maxx, maxy;
|
|
|
|
double scalex, scaley;
|
|
|
|
};
|
|
|
|
|
2011-09-08 15:33:02 +00:00
|
|
|
/* Plot info with smoothing and one-, two- and three-minute minimums and maximums */
|
|
|
|
struct plot_info {
|
|
|
|
int nr;
|
|
|
|
int maxtime;
|
|
|
|
struct plot_data {
|
|
|
|
int sec;
|
|
|
|
int val;
|
|
|
|
int smoothed;
|
|
|
|
int min[3];
|
|
|
|
int max[3];
|
|
|
|
int avg[3];
|
|
|
|
} entry[];
|
|
|
|
};
|
|
|
|
#define plot_info_size(nr) (sizeof(struct plot_info) + (nr)*sizeof(struct plot_data))
|
|
|
|
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
/* Scale to 0,0 -> maxx,maxy */
|
|
|
|
#define SCALE(gc,x,y) (x)*gc->maxx/gc->scalex,(y)*gc->maxy/gc->scaley
|
|
|
|
|
|
|
|
static void move_to(struct graphics_context *gc, double x, double y)
|
|
|
|
{
|
|
|
|
cairo_move_to(gc->cr, SCALE(gc, x, y));
|
|
|
|
}
|
|
|
|
|
|
|
|
static void line_to(struct graphics_context *gc, double x, double y)
|
|
|
|
{
|
|
|
|
cairo_line_to(gc->cr, SCALE(gc, x, y));
|
|
|
|
}
|
|
|
|
|
2011-08-31 21:15:50 +00:00
|
|
|
#define ROUND_UP(x,y) ((((x)+(y)-1)/(y))*(y))
|
|
|
|
|
2011-08-31 21:35:31 +00:00
|
|
|
/*
|
|
|
|
* When showing dive profiles, we scale things to the
|
|
|
|
* current dive. However, we don't scale past less than
|
|
|
|
* 30 minutes or 90 ft, just so that small dives show
|
|
|
|
* up as such.
|
|
|
|
*/
|
2011-08-31 21:15:50 +00:00
|
|
|
static int round_seconds_up(int seconds)
|
|
|
|
{
|
2011-08-31 21:35:31 +00:00
|
|
|
return MAX(30*60, ROUND_UP(seconds, 60*10));
|
2011-08-31 21:15:50 +00:00
|
|
|
}
|
|
|
|
|
2011-09-07 16:21:26 +00:00
|
|
|
static int round_depth_up(depth_t depth)
|
2011-08-31 21:15:50 +00:00
|
|
|
{
|
2011-09-07 16:21:26 +00:00
|
|
|
unsigned mm = depth.mm;
|
|
|
|
/* Minimum 30m */
|
|
|
|
return MAX(30000, ROUND_UP(mm+3000, 10000));
|
2011-08-31 21:15:50 +00:00
|
|
|
}
|
|
|
|
|
2011-09-06 22:00:56 +00:00
|
|
|
typedef struct {
|
2011-09-08 01:33:14 +00:00
|
|
|
int size;
|
2011-09-06 22:41:02 +00:00
|
|
|
double r,g,b;
|
2011-09-07 23:52:55 +00:00
|
|
|
enum {CENTER,LEFT} halign;
|
|
|
|
enum {MIDDLE,TOP,BOTTOM} valign;
|
2011-09-06 22:00:56 +00:00
|
|
|
} text_render_options_t;
|
|
|
|
|
2011-09-08 03:55:22 +00:00
|
|
|
static void plot_text(struct graphics_context *gc, const text_render_options_t *tro,
|
2011-09-06 22:00:56 +00:00
|
|
|
double x, double y, const char *fmt, ...)
|
2011-09-06 17:25:01 +00:00
|
|
|
{
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
cairo_t *cr = gc->cr;
|
2011-09-06 17:25:01 +00:00
|
|
|
cairo_text_extents_t extents;
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
double dx, dy;
|
2011-09-06 17:25:01 +00:00
|
|
|
char buffer[80];
|
|
|
|
va_list args;
|
|
|
|
|
|
|
|
va_start(args, fmt);
|
|
|
|
vsnprintf(buffer, sizeof(buffer), fmt, args);
|
|
|
|
va_end(args);
|
|
|
|
|
2011-09-08 01:33:14 +00:00
|
|
|
cairo_set_font_size(cr, tro->size);
|
2011-09-06 17:25:01 +00:00
|
|
|
cairo_text_extents(cr, buffer, &extents);
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
dx = 0;
|
2011-09-07 23:52:55 +00:00
|
|
|
switch (tro->halign) {
|
|
|
|
case CENTER:
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
dx = -(extents.width/2 + extents.x_bearing);
|
2011-09-07 23:52:55 +00:00
|
|
|
break;
|
|
|
|
case LEFT:
|
|
|
|
dx = 0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
switch (tro->valign) {
|
|
|
|
case TOP:
|
|
|
|
dy = extents.height * 1.2;
|
|
|
|
break;
|
|
|
|
case BOTTOM:
|
|
|
|
dy = -extents.height * 0.8;
|
|
|
|
break;
|
|
|
|
case MIDDLE:
|
|
|
|
dy = 0;
|
|
|
|
break;
|
|
|
|
}
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
|
|
|
|
move_to(gc, x, y);
|
|
|
|
cairo_rel_move_to(cr, dx, dy);
|
2011-09-06 17:25:01 +00:00
|
|
|
|
|
|
|
cairo_text_path(cr, buffer);
|
|
|
|
cairo_set_source_rgb(cr, 0, 0, 0);
|
|
|
|
cairo_stroke(cr);
|
|
|
|
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
move_to(gc, x, y);
|
|
|
|
cairo_rel_move_to(cr, dx, dy);
|
|
|
|
|
2011-09-06 22:00:56 +00:00
|
|
|
cairo_set_source_rgb(cr, tro->r, tro->g, tro->b);
|
2011-09-06 17:25:01 +00:00
|
|
|
cairo_show_text(cr, buffer);
|
|
|
|
}
|
|
|
|
|
2011-09-08 03:55:22 +00:00
|
|
|
static void render_depth_sample(struct graphics_context *gc, struct sample *sample, const text_render_options_t *tro)
|
2011-09-08 01:57:04 +00:00
|
|
|
{
|
|
|
|
int sec = sample->time.seconds;
|
|
|
|
depth_t depth = sample->depth;
|
|
|
|
const char *fmt;
|
|
|
|
double d;
|
|
|
|
|
|
|
|
switch (output_units.length) {
|
|
|
|
case METERS:
|
|
|
|
d = depth.mm / 1000.0;
|
|
|
|
fmt = "%.1f";
|
|
|
|
break;
|
|
|
|
case FEET:
|
|
|
|
d = to_feet(depth);
|
|
|
|
fmt = "%.0f";
|
|
|
|
break;
|
|
|
|
}
|
2011-09-08 03:55:22 +00:00
|
|
|
plot_text(gc, tro, sec, depth.mm, fmt, d);
|
2011-09-08 01:57:04 +00:00
|
|
|
}
|
|
|
|
|
2011-09-06 19:16:39 +00:00
|
|
|
/*
|
2011-09-07 23:38:22 +00:00
|
|
|
* Find the next minimum/maximum point.
|
2011-09-06 19:16:39 +00:00
|
|
|
*
|
|
|
|
* We exit early if we hit "enough" of a depth reversal,
|
|
|
|
* which is roughly 10 feet.
|
|
|
|
*/
|
2011-09-07 20:51:35 +00:00
|
|
|
static struct sample *next_minmax(struct sample *sample, struct sample *end, int minmax)
|
2011-09-06 17:25:01 +00:00
|
|
|
{
|
2011-09-06 19:16:39 +00:00
|
|
|
const int enough = 3000;
|
2011-09-07 20:35:59 +00:00
|
|
|
struct sample *result;
|
2011-09-07 23:21:35 +00:00
|
|
|
int depthlimit;
|
2011-09-06 17:25:01 +00:00
|
|
|
|
2011-09-07 20:35:59 +00:00
|
|
|
if (sample >= end)
|
2011-09-06 17:25:01 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
depthlimit = sample->depth.mm;
|
2011-09-07 20:35:59 +00:00
|
|
|
result = NULL;
|
2011-09-06 17:25:01 +00:00
|
|
|
|
|
|
|
for (;;) {
|
2011-09-08 04:12:13 +00:00
|
|
|
int depth;
|
2011-09-06 17:25:01 +00:00
|
|
|
|
|
|
|
sample++;
|
2011-09-07 20:35:59 +00:00
|
|
|
if (sample >= end)
|
|
|
|
return NULL;
|
2011-09-06 17:25:01 +00:00
|
|
|
depth = sample->depth.mm;
|
2011-09-06 19:16:39 +00:00
|
|
|
|
|
|
|
if (minmax) {
|
|
|
|
if (depth <= depthlimit) {
|
|
|
|
if (depthlimit - depth > enough)
|
|
|
|
break;
|
2011-09-06 17:25:01 +00:00
|
|
|
continue;
|
2011-09-06 19:16:39 +00:00
|
|
|
}
|
2011-09-06 17:25:01 +00:00
|
|
|
} else {
|
2011-09-06 19:16:39 +00:00
|
|
|
if (depth >= depthlimit) {
|
|
|
|
if (depth - depthlimit > enough)
|
|
|
|
break;
|
2011-09-06 17:25:01 +00:00
|
|
|
continue;
|
2011-09-06 19:16:39 +00:00
|
|
|
}
|
2011-09-06 17:25:01 +00:00
|
|
|
}
|
|
|
|
|
2011-09-07 20:35:59 +00:00
|
|
|
result = sample;
|
2011-09-06 19:16:39 +00:00
|
|
|
depthlimit = depth;
|
2011-09-06 17:25:01 +00:00
|
|
|
}
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
2011-09-07 23:03:16 +00:00
|
|
|
static void plot_text_samples(struct graphics_context *gc, struct sample *a, struct sample *b)
|
2011-09-07 20:51:35 +00:00
|
|
|
{
|
2011-09-08 03:55:22 +00:00
|
|
|
static const text_render_options_t deep = {14, 1.0, 0.2, 0.2, CENTER, TOP};
|
|
|
|
static const text_render_options_t shallow = {14, 1.0, 0.2, 0.2, CENTER, BOTTOM};
|
|
|
|
|
2011-09-07 23:38:22 +00:00
|
|
|
for (;;) {
|
|
|
|
if (b <= a)
|
|
|
|
break;
|
|
|
|
a = next_minmax(a, b, 1);
|
|
|
|
if (!a)
|
2011-09-08 01:57:04 +00:00
|
|
|
break;
|
2011-09-08 03:55:22 +00:00
|
|
|
render_depth_sample(gc, a, &deep);
|
2011-09-07 23:38:22 +00:00
|
|
|
a = next_minmax(a, b, 0);
|
|
|
|
if (!a)
|
|
|
|
break;
|
2011-09-08 03:55:22 +00:00
|
|
|
if (a->depth.mm < 2500)
|
|
|
|
continue;
|
|
|
|
render_depth_sample(gc, a, &shallow);
|
2011-09-07 20:51:35 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
static void plot_depth_text(struct dive *dive, struct graphics_context *gc)
|
2011-09-06 19:36:52 +00:00
|
|
|
{
|
2011-09-07 20:35:59 +00:00
|
|
|
struct sample *sample, *end;
|
2011-09-06 19:36:52 +00:00
|
|
|
int maxtime, maxdepth;
|
|
|
|
|
|
|
|
/* Get plot scaling limits */
|
|
|
|
maxtime = round_seconds_up(dive->duration.seconds);
|
2011-09-07 16:21:26 +00:00
|
|
|
maxdepth = round_depth_up(dive->maxdepth);
|
2011-09-06 19:36:52 +00:00
|
|
|
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
gc->scalex = maxtime;
|
|
|
|
gc->scaley = maxdepth;
|
2011-09-06 19:36:52 +00:00
|
|
|
|
2011-09-07 20:35:59 +00:00
|
|
|
sample = dive->sample;
|
2011-09-07 23:21:35 +00:00
|
|
|
end = dive->sample + dive->samples;
|
2011-09-07 20:35:59 +00:00
|
|
|
|
2011-09-07 23:03:16 +00:00
|
|
|
plot_text_samples(gc, sample, end);
|
2011-09-06 19:36:52 +00:00
|
|
|
}
|
|
|
|
|
2011-09-08 16:32:08 +00:00
|
|
|
static void plot_smoothed_profile(struct graphics_context *gc, struct plot_info *pi)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
struct plot_data *entry = pi->entry;
|
|
|
|
|
|
|
|
cairo_set_source_rgba(gc->cr, 1, 0.2, 0.2, 0.20);
|
|
|
|
move_to(gc, entry->sec, entry->smoothed);
|
|
|
|
for (i = 1; i < pi->nr; i++) {
|
|
|
|
entry++;
|
|
|
|
line_to(gc, entry->sec, entry->smoothed);
|
|
|
|
}
|
|
|
|
cairo_stroke(gc->cr);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void plot_minmax_profile_minute(struct graphics_context *gc, struct plot_info *pi,
|
|
|
|
int index, double a)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
struct plot_data *entry = pi->entry;
|
|
|
|
|
|
|
|
cairo_set_source_rgba(gc->cr, 1, 0.2, 1, a);
|
|
|
|
move_to(gc, entry->sec, entry->min[index]);
|
|
|
|
for (i = 1; i < pi->nr; i++) {
|
|
|
|
entry++;
|
|
|
|
line_to(gc, entry->sec, entry->min[index]);
|
|
|
|
}
|
|
|
|
for (i = 1; i < pi->nr; i++) {
|
|
|
|
line_to(gc, entry->sec, entry->max[index]);
|
|
|
|
entry--;
|
|
|
|
}
|
|
|
|
cairo_close_path(gc->cr);
|
|
|
|
cairo_fill(gc->cr);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void plot_minmax_profile(struct graphics_context *gc, struct plot_info *pi)
|
|
|
|
{
|
|
|
|
plot_minmax_profile_minute(gc, pi, 2, 0.1);
|
|
|
|
plot_minmax_profile_minute(gc, pi, 1, 0.1);
|
|
|
|
plot_minmax_profile_minute(gc, pi, 0, 0.1);
|
|
|
|
}
|
|
|
|
|
2011-09-08 15:33:02 +00:00
|
|
|
static void plot_depth_profile(struct dive *dive, struct graphics_context *gc, struct plot_info *pi)
|
2011-08-31 21:15:50 +00:00
|
|
|
{
|
2011-09-08 15:33:02 +00:00
|
|
|
int i;
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
cairo_t *cr = gc->cr;
|
2011-08-31 21:23:35 +00:00
|
|
|
int begins, sec, depth;
|
2011-09-08 15:33:02 +00:00
|
|
|
struct plot_data *entry;
|
2011-09-07 16:21:26 +00:00
|
|
|
int maxtime, maxdepth, marker;
|
2011-08-31 21:15:50 +00:00
|
|
|
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
cairo_set_line_width(gc->cr, 2);
|
2011-08-31 21:15:50 +00:00
|
|
|
|
|
|
|
/* Get plot scaling limits */
|
|
|
|
maxtime = round_seconds_up(dive->duration.seconds);
|
2011-09-07 16:21:26 +00:00
|
|
|
maxdepth = round_depth_up(dive->maxdepth);
|
2011-08-31 21:15:50 +00:00
|
|
|
|
2011-09-03 20:55:36 +00:00
|
|
|
/* Time markers: every 5 min */
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
gc->scalex = maxtime;
|
|
|
|
gc->scaley = 1.0;
|
2011-09-03 20:55:36 +00:00
|
|
|
for (i = 5*60; i < maxtime; i += 5*60) {
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
move_to(gc, i, 0);
|
|
|
|
line_to(gc, i, 1);
|
2011-09-03 20:55:36 +00:00
|
|
|
}
|
|
|
|
|
2011-09-07 16:21:26 +00:00
|
|
|
/* Depth markers: every 30 ft or 10 m*/
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
gc->scalex = 1.0;
|
|
|
|
gc->scaley = maxdepth;
|
2011-09-07 16:21:26 +00:00
|
|
|
switch (output_units.length) {
|
|
|
|
case METERS: marker = 10000; break;
|
|
|
|
case FEET: marker = 9144; break; /* 30 ft */
|
|
|
|
}
|
|
|
|
|
2011-08-31 21:15:50 +00:00
|
|
|
cairo_set_source_rgba(cr, 1, 1, 1, 0.5);
|
2011-09-07 16:21:26 +00:00
|
|
|
for (i = marker; i < maxdepth; i += marker) {
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
move_to(gc, 0, i);
|
|
|
|
line_to(gc, 1, i);
|
2011-08-31 21:15:50 +00:00
|
|
|
}
|
2011-09-03 20:55:36 +00:00
|
|
|
cairo_stroke(cr);
|
2011-08-31 21:15:50 +00:00
|
|
|
|
2011-09-03 20:55:36 +00:00
|
|
|
/* Show mean depth */
|
|
|
|
cairo_set_source_rgba(cr, 1, 0.2, 0.2, 0.40);
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
move_to(gc, 0, dive->meandepth.mm);
|
|
|
|
line_to(gc, 1, dive->meandepth.mm);
|
2011-08-31 21:15:50 +00:00
|
|
|
cairo_stroke(cr);
|
|
|
|
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
gc->scalex = maxtime;
|
2011-08-31 21:15:50 +00:00
|
|
|
|
2011-09-08 16:32:08 +00:00
|
|
|
plot_smoothed_profile(gc, pi);
|
|
|
|
plot_minmax_profile(gc, pi);
|
|
|
|
|
2011-09-08 15:33:02 +00:00
|
|
|
entry = pi->entry;
|
2011-08-31 21:15:50 +00:00
|
|
|
cairo_set_source_rgba(cr, 1, 0.2, 0.2, 0.80);
|
2011-09-08 15:33:02 +00:00
|
|
|
begins = entry->sec;
|
|
|
|
move_to(gc, entry->sec, entry->val);
|
|
|
|
for (i = 1; i < pi->nr; i++) {
|
|
|
|
entry++;
|
|
|
|
sec = entry->sec;
|
2011-09-06 23:44:20 +00:00
|
|
|
if (sec <= maxtime) {
|
2011-09-08 15:33:02 +00:00
|
|
|
depth = entry->val;
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
line_to(gc, sec, depth);
|
2011-09-06 23:44:20 +00:00
|
|
|
}
|
2011-08-31 21:15:50 +00:00
|
|
|
}
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
gc->scaley = 1.0;
|
|
|
|
line_to(gc, MIN(sec,maxtime), 0);
|
|
|
|
line_to(gc, begins, 0);
|
2011-08-31 21:23:35 +00:00
|
|
|
cairo_close_path(cr);
|
|
|
|
cairo_set_source_rgba(cr, 1, 0.2, 0.2, 0.20);
|
|
|
|
cairo_fill_preserve(cr);
|
|
|
|
cairo_set_source_rgba(cr, 1, 0.2, 0.2, 0.80);
|
2011-08-31 21:15:50 +00:00
|
|
|
cairo_stroke(cr);
|
2011-09-03 20:19:26 +00:00
|
|
|
}
|
|
|
|
|
2011-09-06 22:00:56 +00:00
|
|
|
/* gets both the actual start and end pressure as well as the scaling factors */
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
static int get_cylinder_pressure_range(struct dive *dive, struct graphics_context *gc,
|
|
|
|
pressure_t *startp, pressure_t *endp)
|
2011-09-03 20:19:26 +00:00
|
|
|
{
|
|
|
|
int i;
|
2011-09-07 02:28:31 +00:00
|
|
|
int min, max;
|
2011-09-03 20:19:26 +00:00
|
|
|
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
gc->scalex = round_seconds_up(dive->duration.seconds);
|
2011-09-03 20:19:26 +00:00
|
|
|
|
|
|
|
max = 0;
|
2011-09-07 02:14:56 +00:00
|
|
|
min = 5000000;
|
2011-09-06 22:00:56 +00:00
|
|
|
if (startp)
|
2011-09-07 02:14:56 +00:00
|
|
|
startp->mbar = endp->mbar = 0;
|
2011-09-06 22:00:56 +00:00
|
|
|
|
2011-09-03 20:19:26 +00:00
|
|
|
for (i = 0; i < dive->samples; i++) {
|
2011-09-07 02:28:31 +00:00
|
|
|
int mbar;
|
2011-09-03 20:19:26 +00:00
|
|
|
struct sample *sample = dive->sample + i;
|
|
|
|
|
2011-09-05 16:12:54 +00:00
|
|
|
/* FIXME! We only track cylinder 0 right now */
|
|
|
|
if (sample->cylinderindex)
|
|
|
|
continue;
|
2011-09-07 02:14:56 +00:00
|
|
|
mbar = sample->cylinderpressure.mbar;
|
|
|
|
if (!mbar)
|
2011-09-03 20:19:26 +00:00
|
|
|
continue;
|
2011-09-07 02:14:56 +00:00
|
|
|
if (mbar < min)
|
|
|
|
min = mbar;
|
|
|
|
if (mbar > max)
|
|
|
|
max = mbar;
|
2011-09-03 20:19:26 +00:00
|
|
|
}
|
2011-09-07 02:28:31 +00:00
|
|
|
if (startp)
|
|
|
|
startp->mbar = max;
|
2011-09-06 22:00:56 +00:00
|
|
|
if (endp)
|
2011-09-07 02:28:31 +00:00
|
|
|
endp->mbar = min;
|
2011-09-03 20:19:26 +00:00
|
|
|
if (!max)
|
|
|
|
return 0;
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
gc->scaley = max * 1.5;
|
2011-09-03 20:19:26 +00:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
static void plot_cylinder_pressure(struct dive *dive, struct graphics_context *gc)
|
2011-09-03 20:19:26 +00:00
|
|
|
{
|
2011-09-06 14:30:48 +00:00
|
|
|
int i, sec = -1;
|
2011-09-03 20:19:26 +00:00
|
|
|
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
if (!get_cylinder_pressure_range(dive, gc, NULL, NULL))
|
2011-09-03 20:19:26 +00:00
|
|
|
return;
|
|
|
|
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
cairo_set_source_rgba(gc->cr, 0.2, 1.0, 0.2, 0.80);
|
2011-09-03 20:19:26 +00:00
|
|
|
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
move_to(gc, 0, dive->cylinder[0].start.mbar);
|
2011-09-03 20:19:26 +00:00
|
|
|
for (i = 1; i < dive->samples; i++) {
|
2011-09-06 14:30:48 +00:00
|
|
|
int mbar;
|
2011-09-03 20:19:26 +00:00
|
|
|
struct sample *sample = dive->sample + i;
|
|
|
|
|
2011-09-04 03:31:18 +00:00
|
|
|
mbar = sample->cylinderpressure.mbar;
|
2011-09-03 20:19:26 +00:00
|
|
|
if (!mbar)
|
|
|
|
continue;
|
2011-09-06 14:30:48 +00:00
|
|
|
sec = sample->time.seconds;
|
2011-09-06 23:44:20 +00:00
|
|
|
if (sec <= dive->duration.seconds)
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
line_to(gc, sec, mbar);
|
2011-09-03 20:19:26 +00:00
|
|
|
}
|
2011-09-06 14:30:48 +00:00
|
|
|
/*
|
|
|
|
* We may have "surface time" events, in which case we don't go
|
|
|
|
* back to dive duration
|
|
|
|
*/
|
|
|
|
if (sec < dive->duration.seconds)
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
line_to(gc, dive->duration.seconds, dive->cylinder[0].end.mbar);
|
|
|
|
cairo_stroke(gc->cr);
|
2011-09-03 20:19:26 +00:00
|
|
|
}
|
|
|
|
|
2011-09-06 21:46:46 +00:00
|
|
|
/*
|
|
|
|
* Return air usage (in liters).
|
|
|
|
*/
|
|
|
|
static double calculate_airuse(struct dive *dive)
|
|
|
|
{
|
|
|
|
double airuse = 0;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < MAX_CYLINDERS; i++) {
|
|
|
|
cylinder_t *cyl = dive->cylinder + i;
|
|
|
|
int size = cyl->type.size.mliter;
|
|
|
|
double kilo_atm;
|
|
|
|
|
|
|
|
if (!size)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
kilo_atm = (cyl->start.mbar - cyl->end.mbar) / 1013250.0;
|
|
|
|
|
|
|
|
/* Liters of air at 1 atm == milliliters at 1k atm*/
|
|
|
|
airuse += kilo_atm * size;
|
|
|
|
}
|
|
|
|
return airuse;
|
|
|
|
}
|
|
|
|
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
static void plot_info(struct dive *dive, struct graphics_context *gc)
|
2011-09-06 21:46:46 +00:00
|
|
|
{
|
2011-09-08 01:33:14 +00:00
|
|
|
text_render_options_t tro = {10, 0.2, 1.0, 0.2, LEFT, TOP};
|
2011-09-06 21:46:46 +00:00
|
|
|
const double liters_per_cuft = 28.317;
|
2011-09-07 02:28:31 +00:00
|
|
|
const char *unit;
|
2011-09-06 21:46:46 +00:00
|
|
|
double airuse;
|
|
|
|
|
|
|
|
airuse = calculate_airuse(dive);
|
|
|
|
if (!airuse)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* I really need to start addign some unit setting thing */
|
2011-09-07 02:28:31 +00:00
|
|
|
switch (output_units.volume) {
|
|
|
|
case LITER:
|
|
|
|
unit = "l";
|
|
|
|
break;
|
|
|
|
case CUFT:
|
|
|
|
unit = "cuft";
|
|
|
|
airuse /= liters_per_cuft;
|
|
|
|
break;
|
|
|
|
}
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
plot_text(gc, &tro, 0.8, 0.8, "vol: %4.2f %s", airuse, unit);
|
2011-09-06 21:46:46 +00:00
|
|
|
if (dive->duration.seconds) {
|
|
|
|
double pressure = 1 + (dive->meandepth.mm / 10000.0);
|
|
|
|
double sac = airuse / pressure * 60 / dive->duration.seconds;
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
plot_text(gc, &tro, 0.8, 0.85, "SAC: %4.2f %s/min", sac, unit);
|
2011-09-06 22:17:24 +00:00
|
|
|
}
|
|
|
|
}
|
2011-09-06 22:00:56 +00:00
|
|
|
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
static void plot_cylinder_pressure_text(struct dive *dive, struct graphics_context *gc)
|
2011-09-06 22:00:56 +00:00
|
|
|
{
|
2011-09-07 02:14:56 +00:00
|
|
|
pressure_t startp, endp;
|
2011-09-06 22:00:56 +00:00
|
|
|
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
if (get_cylinder_pressure_range(dive, gc, &startp, &endp)) {
|
2011-09-07 02:28:31 +00:00
|
|
|
int start, end;
|
|
|
|
const char *unit = "bar";
|
|
|
|
|
|
|
|
switch (output_units.pressure) {
|
|
|
|
case PASCAL:
|
|
|
|
start = startp.mbar * 100;
|
|
|
|
end = startp.mbar * 100;
|
|
|
|
unit = "pascal";
|
|
|
|
break;
|
|
|
|
case BAR:
|
2011-09-07 15:35:35 +00:00
|
|
|
start = (startp.mbar + 500) / 1000;
|
|
|
|
end = (endp.mbar + 500) / 1000;
|
2011-09-07 02:28:31 +00:00
|
|
|
unit = "bar";
|
|
|
|
break;
|
|
|
|
case PSI:
|
2011-09-07 15:35:35 +00:00
|
|
|
start = to_PSI(startp);
|
|
|
|
end = to_PSI(endp);
|
2011-09-07 02:28:31 +00:00
|
|
|
unit = "psi";
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2011-09-08 01:33:14 +00:00
|
|
|
text_render_options_t tro = {10, 0.2, 1.0, 0.2, LEFT, TOP};
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
plot_text(gc, &tro, 0, startp.mbar, "%d %s", start, unit);
|
|
|
|
plot_text(gc, &tro, dive->duration.seconds, endp.mbar,
|
2011-09-07 02:28:31 +00:00
|
|
|
"%d %s", end, unit);
|
2011-09-06 21:46:46 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-09-08 15:33:02 +00:00
|
|
|
static void analyze_plot_info_minmax_minute(struct plot_data *entry, struct plot_data *first, struct plot_data *last, int index)
|
|
|
|
{
|
|
|
|
struct plot_data *p = entry;
|
|
|
|
int time = entry->sec;
|
|
|
|
int seconds = 60*(index+1);
|
|
|
|
int min, max, avg, nr;
|
|
|
|
|
|
|
|
/* Go back 'seconds' in time */
|
|
|
|
while (p > first) {
|
|
|
|
if (p[-1].sec < time - seconds)
|
|
|
|
break;
|
|
|
|
p--;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Then go forward until we hit an entry past the time */
|
|
|
|
min = max = avg = p->val;
|
|
|
|
nr = 1;
|
|
|
|
while (++p < last) {
|
|
|
|
int val = p->val;
|
|
|
|
if (p->sec > time + seconds)
|
|
|
|
break;
|
|
|
|
avg += val;
|
|
|
|
nr ++;
|
|
|
|
if (val < min)
|
|
|
|
min = val;
|
|
|
|
if (val > max)
|
|
|
|
max = val;
|
|
|
|
}
|
|
|
|
entry->min[index] = min;
|
|
|
|
entry->max[index] = max;
|
|
|
|
entry->avg[index] = (avg + nr/2) / nr;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void analyze_plot_info_minmax(struct plot_data *entry, struct plot_data *first, struct plot_data *last)
|
|
|
|
{
|
|
|
|
analyze_plot_info_minmax_minute(entry, first, last, 0);
|
|
|
|
analyze_plot_info_minmax_minute(entry, first, last, 1);
|
|
|
|
analyze_plot_info_minmax_minute(entry, first, last, 2);
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct plot_info *analyze_plot_info(struct plot_info *pi)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
int nr = pi->nr;
|
|
|
|
|
|
|
|
/* Smoothing function: 5-point triangular smooth */
|
|
|
|
for (i = 2; i < nr-2; i++) {
|
|
|
|
struct plot_data *entry = pi->entry+i;
|
|
|
|
int val;
|
|
|
|
|
|
|
|
val = entry[-2].val + 2*entry[-1].val + 3*entry[0].val + 2*entry[1].val + entry[2].val;
|
|
|
|
entry->smoothed = (val+4) / 9;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* One-, two- and three-minute minmax data */
|
|
|
|
for (i = 0; i < nr; i++) {
|
|
|
|
struct plot_data *entry = pi->entry +i;
|
|
|
|
analyze_plot_info_minmax(entry, pi->entry, pi->entry+nr);
|
|
|
|
}
|
|
|
|
|
|
|
|
return pi;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Create a plot-info with smoothing and ranged min/max
|
|
|
|
*
|
|
|
|
* This also makes sure that we have extra empty events on both
|
|
|
|
* sides, so that you can do end-points without having to worry
|
|
|
|
* about it.
|
|
|
|
*/
|
|
|
|
static struct plot_info *depth_plot_info(struct dive *dive)
|
|
|
|
{
|
|
|
|
int i, nr = dive->samples + 4, sec;
|
|
|
|
size_t alloc_size = plot_info_size(nr);
|
|
|
|
struct plot_info *pi;
|
|
|
|
|
|
|
|
pi = malloc(alloc_size);
|
|
|
|
if (!pi)
|
|
|
|
return pi;
|
|
|
|
memset(pi, 0, alloc_size);
|
|
|
|
pi->nr = nr;
|
|
|
|
sec = 0;
|
|
|
|
for (i = 0; i < dive->samples; i++) {
|
|
|
|
struct sample *sample = dive->sample+i;
|
|
|
|
struct plot_data *entry = pi->entry + i + 2;
|
|
|
|
|
|
|
|
sec = entry->sec = sample->time.seconds;
|
|
|
|
entry->val = sample->depth.mm;
|
|
|
|
}
|
|
|
|
/* Fill in the last two entries with empty values but valid times */
|
|
|
|
i = dive->samples + 2;
|
|
|
|
pi->entry[i].sec = sec + 20;
|
|
|
|
pi->entry[i+1].sec = sec + 40;
|
|
|
|
|
|
|
|
return analyze_plot_info(pi);
|
|
|
|
}
|
|
|
|
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
static void plot(struct graphics_context *gc, int w, int h, struct dive *dive)
|
2011-09-03 20:19:26 +00:00
|
|
|
{
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
double topx, topy;
|
2011-09-08 15:33:02 +00:00
|
|
|
struct plot_info *pi = depth_plot_info(dive);
|
2011-09-03 20:19:26 +00:00
|
|
|
|
|
|
|
topx = w / 20.0;
|
|
|
|
topy = h / 20.0;
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
cairo_translate(gc->cr, topx, topy);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We can use "cairo_translate()" because that doesn't
|
|
|
|
* scale line width etc. But the actual scaling we need
|
|
|
|
* do set up ourselves..
|
|
|
|
*
|
|
|
|
* Snif. What a pity.
|
|
|
|
*/
|
|
|
|
gc->maxx = (w - 2*topx);
|
|
|
|
gc->maxy = (h - 2*topy);
|
2011-09-03 20:19:26 +00:00
|
|
|
|
2011-09-06 19:36:52 +00:00
|
|
|
/* Cylinder pressure plot */
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
plot_cylinder_pressure(dive, gc);
|
2011-09-06 19:36:52 +00:00
|
|
|
|
2011-09-03 20:19:26 +00:00
|
|
|
/* Depth profile */
|
2011-09-08 15:33:02 +00:00
|
|
|
plot_depth_profile(dive, gc, pi);
|
2011-09-03 20:19:26 +00:00
|
|
|
|
2011-09-06 19:36:52 +00:00
|
|
|
/* Text on top of all graphs.. */
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
plot_depth_text(dive, gc);
|
|
|
|
plot_cylinder_pressure_text(dive, gc);
|
2011-08-31 21:15:50 +00:00
|
|
|
|
2011-09-06 21:46:46 +00:00
|
|
|
/* And info box in the lower right corner.. */
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
gc->scalex = gc->scaley = 1.0;
|
|
|
|
plot_info(dive, gc);
|
2011-09-06 21:46:46 +00:00
|
|
|
|
2011-08-31 21:15:50 +00:00
|
|
|
/* Bounding box last */
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
cairo_set_source_rgb(gc->cr, 1, 1, 1);
|
|
|
|
move_to(gc, 0, 0);
|
|
|
|
line_to(gc, 0, 1);
|
|
|
|
line_to(gc, 1, 1);
|
|
|
|
line_to(gc, 1, 0);
|
|
|
|
cairo_close_path(gc->cr);
|
|
|
|
cairo_stroke(gc->cr);
|
2011-08-31 21:15:50 +00:00
|
|
|
|
|
|
|
}
|
|
|
|
|
2011-08-31 17:20:46 +00:00
|
|
|
static gboolean expose_event(GtkWidget *widget, GdkEventExpose *event, gpointer data)
|
|
|
|
{
|
2011-08-31 23:40:22 +00:00
|
|
|
struct dive *dive = current_dive;
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
struct graphics_context gc;
|
2011-08-31 21:15:50 +00:00
|
|
|
int w,h;
|
|
|
|
|
|
|
|
w = widget->allocation.width;
|
|
|
|
h = widget->allocation.height;
|
2011-08-31 17:20:46 +00:00
|
|
|
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
gc.cr = gdk_cairo_create(widget->window);
|
|
|
|
cairo_set_source_rgb(gc.cr, 0, 0, 0);
|
|
|
|
cairo_paint(gc.cr);
|
2011-08-31 17:20:46 +00:00
|
|
|
|
2011-09-03 20:19:26 +00:00
|
|
|
if (dive)
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
plot(&gc, w, h, dive);
|
2011-08-31 17:20:46 +00:00
|
|
|
|
Fix up horribly broken cairo scaling
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-07 21:37:47 +00:00
|
|
|
cairo_destroy(gc.cr);
|
2011-08-31 17:20:46 +00:00
|
|
|
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
2011-09-04 17:01:30 +00:00
|
|
|
GtkWidget *dive_profile_widget(void)
|
2011-08-31 17:20:46 +00:00
|
|
|
{
|
|
|
|
GtkWidget *da;
|
|
|
|
|
|
|
|
da = gtk_drawing_area_new();
|
|
|
|
gtk_widget_set_size_request(da, 450, 350);
|
|
|
|
g_signal_connect(da, "expose_event", G_CALLBACK(expose_event), NULL);
|
|
|
|
|
2011-09-04 17:01:30 +00:00
|
|
|
return da;
|
2011-08-31 17:20:46 +00:00
|
|
|
}
|