Re: [boost] GUI coordinate units (Was: GUI foundations)

In-Reply-To: <4342AC3C.1060100@sympatico.ca> seefeld@sympatico.ca (Stefan Seefeld) wrote (abridged):
Exactly. To be clear: moving from a 15" to a 17" monitor would, in my ideal world, have *no* impact on the physical size of the displayed graphics, but rather, would add ~ 1.4" in both dimensions to the useful screen area. How many pixels your display has then only affects the quality of the rendering, exactly as what you were looking for.
Isn't that quite hard? Specifically, it sounds rather like the problem of drawing text nicely at various resolutions. Consider TrueType, or Type 1 Postscript fonts. The basic character shape is defined by vectors, by Bezier curves. To render it prettily, so that, for example, all the vertical strokes on an 'm' are the same thickness regardless of how the letter falls onto the pixel grid, you need to add what Adobe call hints and Microsoft call grid-fitting. Are you intending this system to be usable only on high-res desktop machines? Or are you including hand-held devices, phones and wotnot, that have relatively slow CPUs and where 640x320 is ambitiously high resolution? There is some discussion about TrueType grid-fitting about half-way down this page: http://www.microsoft.com/typography/otspec/TTCH01.htm
Of course, this requires a completely vector-graphics-based GUI, which is still the exception.
Maybe there's a reason for that. I'm not saying don't do it, but I'd recommend doing some experiments that prove it's actually possible before investing too much. -- Dave Harris, Nottingham, UK.

Dave Harris wrote:
In-Reply-To: <4342AC3C.1060100@sympatico.ca> seefeld@sympatico.ca (Stefan Seefeld) wrote (abridged):
Exactly. To be clear: moving from a 15" to a 17" monitor would, in my ideal world, have *no* impact on the physical size of the displayed graphics, but rather, would add ~ 1.4" in both dimensions to the useful screen area. How many pixels your display has then only affects the quality of the rendering, exactly as what you were looking for.
Isn't that quite hard?
Specifically, it sounds rather like the problem of drawing text nicely at various resolutions. Consider TrueType, or Type 1 Postscript fonts. The basic character shape is defined by vectors, by Bezier curves. To render it prettily, so that, for example, all the vertical strokes on an 'm' are the same thickness regardless of how the letter falls onto the pixel grid, you need to add what Adobe call hints and Microsoft call grid-fitting.
Indeed, small objects such as text are a problem, as they either have to have a size that depends on the sub-pixel alignment or they will look bad. I'm not sure what the solution is here. It seems that for small-size objects we have to relax the device-independence a bit. I'm still confident this can be done, since others have done it before (DPS, NeWS, and nowadays MacOS X, I believe).
Are you intending this system to be usable only on high-res desktop machines? Or are you including hand-held devices, phones and wotnot, that have relatively slow CPUs and where 640x320 is ambitiously high resolution?
I'm not sure. It's definitely easier to do on high-res devices.
Of course, this requires a completely vector-graphics-based GUI, which is still the exception.
Maybe there's a reason for that. I'm not saying don't do it, but I'd recommend doing some experiments that prove it's actually possible before investing too much.
Definitely, there are reasons. But as with the Y2K bug, it is mostly a question of how long into the future you plan. Imagine new > 200 dpi devices being ready for production but not usable as no GUIs are available that can deal with that high a resolution. Regards, Stefan

Dave Harris wrote:
Specifically, it sounds rather like the problem of drawing text nicely at various resolutions. Consider TrueType, or Type 1 Postscript fonts. The basic character shape is defined by vectors, by Bezier curves. To render it prettily, so that, for example, all the vertical strokes on an 'm' are the same thickness regardless of how the letter falls onto the pixel grid, you need to add what Adobe call hints and Microsoft call grid-fitting.
Are you intending this system to be usable only on high-res desktop machines? Or are you including hand-held devices, phones and wotnot, that have relatively slow CPUs and where 640x320 is ambitiously high resolution?
There is some discussion about TrueType grid-fitting about half-way down this page: http://www.microsoft.com/typography/otspec/TTCH01.htm
Did you look at the examples on the antigrain.com website? They show that with good anti-aliasing and with subpixel accuracy you get very good results even when the display resolution is lower than the resolutions of the details of the displayed objects. The spirals at http://tinyurl.com/836fe look pretty impressive, IMHO. Regards, m Send instant messages to your online friends http://au.messenger.yahoo.com

Martin Wille wrote:
Dave Harris wrote:
Specifically, it sounds rather like the problem of drawing text nicely at various resolutions. Consider TrueType, or Type 1 Postscript fonts. The basic character shape is defined by vectors, by Bezier curves. To render it prettily, so that, for example, all the vertical strokes on an 'm' are the same thickness regardless of how the letter falls onto the pixel grid, you need to add what Adobe call hints and Microsoft call grid-fitting.
Are you intending this system to be usable only on high-res desktop machines? Or are you including hand-held devices, phones and wotnot, that have relatively slow CPUs and where 640x320 is ambitiously high resolution?
There is some discussion about TrueType grid-fitting about half-way down this page: http://www.microsoft.com/typography/otspec/TTCH01.htm
Did you look at the examples on the antigrain.com website? They show that with good anti-aliasing and with subpixel accuracy you get very good results even when the display resolution is lower than the resolutions of the details of the displayed objects. The spirals at http://tinyurl.com/836fe look pretty impressive, IMHO.
And while you are there, don't forget to see the small "mono" "stereo" buttons. I never thought vector graphics can be this good at this scale. Usually, one ends up drawing such small widgets using bitmaps. Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

On Wed, Oct 05, 2005 at 09:03:38AM +0800, Joel de Guzman <joel@boost-consulting.com> wrote:
And while you are there, don't forget to see the small "mono" "stereo" buttons. I never thought vector graphics can be this good at this scale. Usually, one ends up drawing such small widgets using bitmaps.
Have you seen antigrain doing animations: http://antigrain.com/stuff/particle_demo2.exe http://antigrain.com/stuff/page_demo.exe These to examples are tests for a comercial project Maxim was writing at that time. These links were posted on the agg list several months ago. They also work with wine, but the check and radio button text in the page demo does not show up there. I havent tried these demos in a native windows environment yet, but even through the wine layer these two tests are really fast. I think agg is a perfect choice for a gui library. Regards Andreas Pokorny

Andreas Pokorny wrote:
On Wed, Oct 05, 2005 at 09:03:38AM +0800, Joel de Guzman <joel@boost-consulting.com> wrote:
And while you are there, don't forget to see the small "mono" "stereo" buttons. I never thought vector graphics can be this good at this scale. Usually, one ends up drawing such small widgets using bitmaps.
Have you seen antigrain doing animations: http://antigrain.com/stuff/particle_demo2.exe http://antigrain.com/stuff/page_demo.exe
These to examples are tests for a comercial project Maxim was writing at that time. These links were posted on the agg list several months ago. They also work with wine, but the check and radio button text in the page demo does not show up there. I havent tried these demos in a native windows environment yet, but even through the wine layer these two tests are really fast. I think agg is a perfect choice for a gui library.
That totally blew me away. At default settings with bitmap cache enabled, I get 200+fps on a P4 3GHZ. Amazing! Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

Joel de Guzman wrote:
That totally blew me away. At default settings with bitmap cache enabled, I get 200+fps on a P4 3GHZ. Amazing!
On my small Celeron 1.2Ghz with 394MB of PC133, I was getting ~27fps with bitmap cache enabled. AntiGrain is FAST. Jonathan
participants (6)
-
Andreas Pokorny
-
brangdon@cix.compulink.co.uk
-
Joel de Guzman
-
Jonathan Benedicto
-
Martin Wille
-
Stefan Seefeld