[9fans] Re: moving things in a window

[Theo Honohan <theoh@chiark.greenend.org.uk>]

Kenji Arisawa wrote:
> 
> Russ's usage of mask image is interesting, however the difficult point 
> to apply this mask image to rubber-banding I met was:
> 
> imgmask = allocimage(display, Rect(-Msize-2, -Msize-2, Msize+2, Msize+2),
>                      GREY1, 0, DWhite);
> 
> where Msize is pre-defined as 100.  ^_^

Yes.  I *think* Russ's technique is roughly equivalent to

dst = ((opaque(white,1) held out by ball) in mask) over dst
dst = (ball in mask) over dst

("mask" here isn't the same as Russ's mask; it might the same mask as
used for everything else in that window)

Where "dst" starts off being whatever happens to be behind the ball;
with a "general" ball, say with transparency, you'll have to redraw
any parts of the background that were covered in the previous frame
(or touched by previous drawing operations for this frame), so the
first operation is actually

dst = ((background held out by ball) in mask) over dst

When Russ adds support for other operators to gendraw(), it will get a
lot easier to express things like this. we'll be able to just say
things "background held out by ball", with clipping set appropriately
for efficiency.


Maintaining "background" is easy enough, but if you repeat the above
operations for a stack of moving layers, then you'll usually end up
painting some pixels more than once.  To avoid flickering, you would
need to composite all of your layers together before doing the two
steps above, just once, with "ball" standing for the composition of
all the layers apart from the background.

I think that's a clumsy description of one of the non-hardware related
reasons for double-buffering; if your program thinks in terms of
discrete frames, you must display only finished frames, or the display
will be "wrong" some of the time.  An unfinished raster scan (at the
video level) or an unfinished display list (entirely in software) just
result in different artifacts.

Theo