Scaling and hinting [was Re: composite manager thought]

[Allen Akin]

On Mon, Jan 05, 2004 at 11:20:28AM -0500, Owen Taylor wrote:
|=20
| Because hinting is distortion that depends on scale, I'd think you
| generally don't want to rehint when doing animations, warping windows,
| etc, because you'll see sudden discontinuities as you pass boundaries.

Well, you don't want discontinuities at the transition scales, but that
doesn't necessarily mean you don't want hinting.

In the 3D world, handling multiple scale-dependent representations of an
object is known as the "geometric level-of-detail" problem.  Dealing
with discontinuities is a make-or-break matter for systems like flight
simulators, and the techniques developed for those have carried over
into games and other applications that involve animation.

These techniques range from compositing multiple images to dynamically
subdividing higher-order representations.  "Real-Time Rendering" by
Akenine-M=F6ller and Haines gives a good brief introduction with
references.

I have little experience with text, so I certainly can't argue that such
techniques are *required* to animate window transformations.  However,
they're likely to be feasible (because of hardware support for LOD
transitions in other applications).  More importantly, I think we'd be
neglecting a rich lode of experience to the contrary if we adopt a
systems architecture that can't support them.

| The draft paper at:
|=20
|  http://people.redhat.com/otaylor/grid-fitting/

Excellent paper, by the way.

| I guess what really needs to be addressed here is what we mean when
| by "window size" if we have a scalable user interface. You can't
| ignore the pixel grid until you get to at least 200dpi. But=20
|=20
|  - scaling
|  - non-uniform scaling
|  - multiple scaled views
|=20
| All put considerable strain on the concept that a window is just a=20
| fixed size bitmap.

Agreed.

|  - Complex: You define all scaling/warping/etc to happen at the
|    application level. Which sounds like what you are describing
|    below.=20

Yes and no.  I would imagine that the basic operations would be
performed by GPU programs consisting of linked components, where some
components (e.g. scaling computations) are provided by the compositing
manager, and others (e.g. glyph rendering) are provided by toolkits
invoked by the apps.  Still higher-level functions, particularly those
that require global information (e.g. layout) are more likely to be
handled by CPU code in toolkits than in GPU code, whatever its source.

| That sounds like a real challenge to explain to application=20
| programmers :-)=20

Games programmers routinely handle stuff that's a lot more complicated.  =
:-)

The architectural challenge is deciding where to make the cuts and what
information needs to flow between components.  I gave the example of
parametric derivatives because that's sufficient for all the geometric
LOD algorithms with which I'm familiar.  Maybe that's too low-level to
be exposed by a toolkit.  But I suspect if it's expressed in terms more
familiar to the target audience, it wouldn't be a problem.  For example,
calling it a 2-by-2 scaling matrix might do the trick.

Allen