Boost logo

Boost :

From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2005-10-04 14:26:07

Dave Harris wrote:
> In-Reply-To: <43426645.30304_at_[hidden]>
> john.lists_at_[hidden] (John Torjo) wrote (abridged):
>>And, about usability in code. Why would I want in my program, both:
>>gui::rect<pc,double> and gui::rect<pc,int> ?
> For my apps I have found there needs to be two levels. There's a
> device/raster level, which wants to use pixels and ints, and there's a
> logical/world level, which uses units like inches or cm and floating
> point.
> The device/raster level uses pixels and ints because that's what raster
> hardware uses. This is not something you can really abstract away from.
> For example, it's important to scroll by an integral number of pixels else
> anti-aliasing makes the lines change colour.

You make a very interesting point here. For objects whose dimensions are
comparable to the pixel grid it becomes difficult to be device independent
or else rasterization will yield bad results.
I agree getting this right is hard, but I'm not yet ready to throw out
device independence. May be this can be done by encapsulating more of
the text processing inside the renderer ? It's definitely something
that needs flexibility as different domains have different requirements

> The logical/world level needs to be device-independant. It probably needs
> to be scale-invariant too; for example, a rectangle that measures 2x3
> needs to keep its aspect ratio if you halve its size. My employers
> actually use ints and very small units - 1/72000ths of an inch - which are
> also the units used by Postscript and PDF. That decision now seems dated
> to me and more and more of my geometry code is moving to floating point.
> It works better.

It certainly makes life easier, but it also has its cost. Some CPUs for
example don't have a FPU, making floating-point compuation expensive.
It might be a good idea to use an integral type (with a small unit,
such as you suggest above) at least in those cases.


Boost list run by bdawes at, gregod at, cpdaniel at, john at