> From: Jeremy Huddleston <[email protected]> > Date: Fri, 14 Oct 2011 18:44:55 -0700 > > Co-authored-by: Jeremy Huddleston <[email protected]> > Signed-off-by: Peter Hutterer <[email protected]> > Reviewed-by: Peter Hutterer <[email protected]> > Reviewed-by: Jeremy Huddleston <[email protected]> > --- > dix/inpututils.c | 63 ++++++++++++++++++++++++ > include/inpututils.h | 6 ++ > test/input.c | 128 > ++++++++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 197 insertions(+), 0 deletions(-) > > diff --git a/dix/inpututils.c b/dix/inpututils.c > index 0a3d3d8..cd45773 100644 > --- a/dix/inpututils.c > +++ b/dix/inpututils.c > @@ -759,3 +759,66 @@ input_option_set_value(InputOption *opt, const char > *value) > if (value) > opt->value = strdup(value); > } > + > + > +/* FP1616/FP3232 conversion functions. > + * Fixed point types are encoded as signed integral and unsigned frac. So any > + * negative number -n.m is encoded as floor(n) + (1 - 0.m). > + */ > +double > +fp1616_to_double(FP1616 in) > +{ > + double ret; > + > + ret = (double)(in >> 16); > + ret += (double)(in & 0xffff) * (1.0 / (1UL << 16)); /* Optimized: > ldexp((double)(in & 0xffff), -16); */ > + return ret;
Hmm, is it just me, or do others also think that this comment makes very little sense? The current implementation is a very readable implementation of a fixed-point to floating-point conversion. The one with ldexp() is less obvious to me since I'd have to look up what ldexp(3) does. The only benefit I can see that the ldexp(3) variant has, is that it is more portable. So I wouldn't call this an optimization. And the comment makes the line (too) long, so I would just drop it. Same for the other comments that are similar. Either way. Reviewed-by: Mark Kettenis <[email protected]> _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
