handling background images

From: Tomas Frydrych (tomas@frydrych.uklinux.net)
Date: Tue Jul 30 2002 - 08:45:46 EDT

  • Next message: j.m.maurer: "Re: handling background images"

    Hi Martin,

    > In my opinion this is part of the way to go but not the whole way. We
    > want to support background images at all levels. From shading in
    > paragraphs to images that cover a whole page. The only to do this
    > successfully is for each run to paint the SEGMENT of the image it
    > covers. So the runs should the paint the image on information provided
    > by it's container.

    It seems to me that what we need is this (on further thought I do not
    like this approach any more, better suggestion is to follow):


    When a run is to draw its bacground, it will check its bacground
    colour and if it is trasparent, it will call drawBackgroundRegion() of
    its parent container, otherwise it will draw with its background colour.

    The fp_Container::drawBackgroundRegion() will do the same: check
    its bacground colour, and if it is not trasparent or image, it will draw
    the region (using _drawBackgroundRegion()), otherwise it will call
    drawBackgroundRegion() of its parent container, and so on.

    This would entirely eliminate the need for fp_Run::update*Color(),
    because the only colour the run would need to know is its very own.
    However, there would be some performance cost, because the run
    would have to work up through the container hierarchy on each
    background drawing, and this might be to much to bear; its hard to
    tell without trying.

    The other, I think much better, option would be to use a similar
    mechanism as the current updateBackgroudColor(), but extended it,
    so that the run would cache not only colors but segements of
    images. If this is done smartly, it would make very limited demands
    on memory, something like this:

    the background image in the container would be viewed by the run
    an n*m matrix of elements; the run would store the width of its own
    section of the image, the height of it, plus i, j indexes to the point in
    the matrix where the region starts. This whole thing could be
    encapsulated in a class, say gr_PartOfImage(), which could be
    passed to a drawing function in the image class itself,
    GR_Image::renderRegion(&gr_PartOfImage p), that would draw the
    region of the section of the image represented by the part. -- More I
    think about this, more I like it, we basically only need 4 * sizeof(int)
    to chache an image of arbitrary size, plus a pointer to the actual
    image class instance to avoid having to go through the parent
    containers to get to it, 20 bytes per run to chache any image;
    considering that often we have 1 run per line, this is not bad at all.

    class gr_PartOfImage
                    void render(UT_uint32 x, UT_uint32 y);

                    UT_uint32 m_iWidth;
                    UT_uint32 m_iHeight;
                    UT_uint32 m_iX;
                    UT_uint32 m_iY;
                    GR_Image * m_pImage;


    gr_PartOfImage::render(UT_uint32 x, UT_uint32 y)
            m_pImage::renderRegion(x,y, m_iX, m_iY, m_iWidth,


    This archive was generated by hypermail 2.1.4 : Tue Jul 30 2002 - 08:54:50 EDT