W3C home > Mailing lists > Public > www-amaya-dev@w3.org > October 1999

RE: can someone explain a little rendering detail?

From: Ly, An <An.Ly@CAI.COM>
Date: Fri, 29 Oct 1999 11:29:43 -0400
Message-ID: <F516E350BFC4D1118F7B00805FC14BC30303659C@usilmse2.cai.com>
To: Irene.Vatton@inrialpes.fr, "Ly, An" <An.Ly@CAI.COM>
Cc: www-amaya-dev@w3.org
Thanks for the response Irene. Please see my comments below. Also, please
see my other response sent earlier today.

Thank you.

> -----Original Message-----
> From: Irene.Vatton@inrialpes.fr [mailto:Irene.Vatton@inrialpes.fr]
> In-reply-to: Your message of Wed, 27 Oct 1999 11:13:48 -0400."
> <F516E350BFC4D1118F7B00805FC14BC302FE0A5A@usilmse2.cai.com> 
> > Hi all,
> > 
> > When an element is drawn, its corresponding boxes are 
> processed. Now the
> > code in RedrawFrameBottom loops through all planes and 
> renders the boxes in
> > their depth order.
> > 
> > There is code in there that also makes sure that the "dirty 
> rectangle" or
> > clipping area intersects the box before it (box) is drawn. 
> My question is,
> > how does the rendering system ensure that, if there's 2 
> boxes (small box
> > inside a bigger box), and the bigger box intersects the 
> clipping area but
> > the smaller box doesn't, that the smaller box will still be 
> rendered?  Since
> A box which intersects the clipping area is rendered. In fact 
> only the part of
> box within the clipping area is displayed. If the smaller box 
> is out of the
> clipping area, it's not rendered.

The case I am thinking of is a smaller box inside a big box:
(see below in fix width font)

|         |
| +-----+ |
| |small| |
| +-----+ |
|  big    |
| +-------+-----+
| |   clip      |
| +-------+-----+

The big box will intersect and redraw. The smaller box will not intersect
and not be updated. But the bigger box may overwrite the smaller box?

> > only the bigger box intersects the clipping area, it is 
> redrawn but then if
> > it clears the area that it covers, the smaller box inside 
> of it will be
> > drawn over. Since the smaller box doesn't intersect the 
> clipping area, it is
> > never redrawn.
> Normally the clear is also limited by the clipping area. So 
> the smaller box
> should not be cleared.

Yes, only the clipping area is cleared. But when the bigger box redraws, the
smaller box will be overdrawn.

> > 
> > Even if you put the bigger box in a deeper plane (higher 
> number), the
> > rendering doesn't appear to take into consideration that 
> the "background" of
> > the smaller box (essentially the bigger box!) has changed, 
> and therefore the
> > smaller box, even if it doesn't intersect the clipping 
> area, must be drawn.
> I'm not sure that the work is well done, but we planned to 
> take into account 
> that
> some boxes have a background to compute the right clipping area.
> Did you detected a case where that happens.

I modified some P boxes that is my test case. Basically, the button draws a
filled P box (button shape) that is the bigger box and the value (button
text) is drawn inside of it.

I don't know if any of the unmodified Amaya elements have this problem...but
maybe it's not easy to produce a test case.

> > Are there some rules in defining the boxes that prevent the 
> above from
> > happening? Should the "smaller" box really have the same 
> dimensions as the
> > "bigger" box? Maybe I made a mistake in defining my boxes?
> That should work when the bigger box has presentation rules:
> Background: color +  FillPattern: backgroundcolor
> + Showbox

In this case, is the bigger box is considered a filled box? Then the
processing is done first, before any of the other boxes get rendered, right?
But then the smaller enclosed box will still not intersect with clip
rectangle so they will not update.
Received on Friday, 29 October 1999 11:30:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:25:43 UTC