From: Tomas Frydrych (tomas@frydrych.uklinux.net)
Date: Tue Jul 30 2002 - 08:45:46 EDT
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):
fp_Container::_drawBackgroundRegion(x,y,width,height);
fp_Container::drawBackgroundRegion(x,y,width,height);
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
{
public:
void render(UT_uint32 x, UT_uint32 y);
private:
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,
m_iHeight);
}
Tomas
This archive was generated by hypermail 2.1.4 : Tue Jul 30 2002 - 08:54:50 EDT