[boost] Rendering Strategies

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...

        [paste]

    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.)

        [snip]

    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
    organization.

    However, a *grid* has special needs. A *document* has special
    needs.
    
    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.
    
    See?

    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]