From: Alan Gutierrez (alan-boost_at_[hidden])
Date: 2004-12-30 04:16:52
I send a message to Noah Stein, where I think I've gotten a bit
closer to what I'm trying to convey with rendering strategies,
so I'm going to paste the relevent part...
I want to drive home the point that hit-testing is easy for
axis-aligned bounding boxes, and complicated visibility and hit
testing is not necessary for a Symbian UI.
Through generic programming, I'd like to leave it out when I
don't need it, not think about it when I don't have to.
The Win32 GDI mistake was to create a tree of graphic objects,
each materialized in memory. Recognizing the common models of
content rendering, you can devise better strategies than the
allocation of a chunk of memory for every axis-aligned bounding
box on the screen. (Or, conversely, throwing up your hands and
saying that anything further is in the application domain. This
is old, this is bad. It's widgets or the pen.)
I agree that you can nest a canvas, in a form, in a document,
and you can do this because of an axis-aligned box convention.
It is exactly what I'd like to be able to do.
Use a *canvas* renderer to render an vector graphics image in
the corner of a button, or use a *document* renderer to draw
formatted tool tips read from a resource file.
(If I'm on a /G/UI that is.)
A nested axis-aligned bounding box paradigm that rules UI
However, a *grid* has special needs. A *document* has special
A *document* should not have to materialize an object for each
axis-aligned bounding box, attaching a font, pen, brush,
background to each. Not when there is an obvious convention of
inheriting styles from the containing bounding box.
Recognize the rendering strategy, then you can optimize design.
For a *document* each box need only be t,l,r,b, and, /and/ can be
disposed of when it is off screen.
For a *grid* you don't need a structure to represent the
axis-alined box, you only need the height of reach row and the
width of each column. Ah, but not of /each/ row and column, you
can have a sparse list that indicates a change in row or column
width, since they tend to be uniform.
A *grid* does not need to keep components in memory, they only
exist when activated.
Materialized axis-aligned boxes are optimal for a *form*. For a
fixed set of axis-aligned boxes, you can create an object, and
take advantage of optimization that comes from using memory.
Materialized axis-aligned boxes are also optimal for
partitioning a window's client area.
Thus my concern that this model will be mistaken for a panacea.
Good for some things. Non-applicable for others.
When it's not applicable, I don't think the library designers
should throw up their hands and go, oh, looks like an
application problem. Here's some grahpics utilities. Good luck.
A *grid* or a *document* or a *form* have conventions that lend
themselves to optimizations.
Am I getting somewhere?
-- Alan Gutierrez - alan_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk