In-Reply-To: <43426645.30304@torjo.com> john.lists@torjo.com (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. 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 may be that boost doesn't need to tackle the logical/world level immediately. The window-manager stuff and the low-level drawing stuff can use pixels and ints. However, at least some programs will want a logical level too when they come to draw.
I'd rather explicit conversion than an attempt to abstract away the differences. Typically there is a world-to-device linear transform that does the conversion. A single matrix operation provides rotation, scrolling and zoom in addition to scaling from inches or centimetres or whatever. -- Dave Harris, Nottingham, UK.
Dave Harris wrote:
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 (http://www.holoweb.net/~liam/glayout/fontsandprinting.html).
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. Regards, Stefan
Marcin Kalicinski wrote:
You bet ! We were porting the Fresco display server to PDAs such as the Sharp Zaurus or the Compaq iPaq (platforms which are targetted by the Qt toolkit, for example). Neither has/had a floating point unit, and as a result, rendering was quite slow. (Well, Fresco has full 3D support, so all coordinate transformations were actual 3x4 FP multiplications.) I can't see any reason why one would not expect boost::gui to run on these platforms. Regards, Stefan
participants (3)
-
brangdon＠cix.compulink.co.uk -
Marcin Kalicinski -
Stefan Seefeld