Re: Why floating point for widget positions
- From: Mike Emmel <mike emmel gmail com>
- To: Owen Taylor <otaylor redhat com>
- Cc: gtk-list gnome org
- Subject: Re: Why floating point for widget positions
- Date: Wed, 23 Mar 2005 09:58:37 -0500
On Wed, 23 Mar 2005 09:29:25 -0500, Owen Taylor <otaylor redhat com> wrote:
> On Tue, 2005-03-22 at 13:59 -0500, Mike Emmel wrote:
> > I've noticed that the GdkEventMotion x y positions are given in
> > floating point coordinates and was wondering why ?
> >
> > I've looking at GTK for embedded use and this is and issue.
>
> There is no *conceivable* way that cast two doubles to ints per
> motion event is going to cause problems, even on a relatively
> slow processor without floating point.
>
> The use of doubles for layout computation (GtkAlignment, say)
> could be more of an issue, but I haven't seen a lot of reports
> of problems from this.
>
> Cairo, coming in GTK+-2.8, is obviously going to be a *lot*
> more of an issue, but I don't really have a good answer there.
> It's at least fixed point when you get down to rasterization,
> but there is a lot of affine transformation before then.
>
> Regards,
> Owen
>
I'm not saying it will per se. First I thought it was a bit strange
when I ran into it
so my intialy question was why ? Next I'm hypersensitve to any
floating point numbers :) Your right making cairo fixed point clean
is a far higher priority but this is what stood out in GTK.
As far as performance impact well generally I test first then decide
you would be surprised at how often the floating point emulation
libraries blow out on the simplest of conversions. As long as its just
the cast and done once then its fine but if the conversion happens in
a loop and does not for some reason get optimized up say its in a
function called from a loop even the conversion becomes a issue. It
does not take long to develop a unhealthy fear of floating point
numbers :)
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]