[9fans] Re: moving things in a window

[9fans] Re: moving things in a window

[Theo Honohan]

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

Re: [9fans] Re: moving things in a window

[andrey mirtchovski]

I asked Russ Cox for an explanation of the code, and I promptly received
one:
(with hopes it's useful and he doesn't mind me sending private email)

--- begin paste ---
/* clean up previous location */
if (osize && clear) {
        draw(imgmask, imgmask->r, display->black, nil, ZP);     // transparent
        fillellipse(imgmask, subpt(oldp, p1), osize, osize, display->white, ZP);        // draw opaque old
        fillellipse(imgmask, ZP, size, size, display->black, ZP);       // cover new

        draw(screen, rectaddpt(imgmask->r, p1), display->white, imgmask, imgmask->r.min);
}

We start with a black square.
Then we draw a white circle where the old circle was.
Then we draw a black circle where the new circle will be.

The result is a black image with a sliver of white corresponding to
the area of the old circle that is outside the new circle.

Interpreted as a mask, black is transparent; white opaque.
So the mask says ``only draw where the old circle was
but the new circle is not''.
The final draw puts white down in those places.
--- end paste --

the explanation may be a bit too high level for you though :)


On Tue, 26 Sep 2000, Theo Honohan wrote:
[snip]

Re: [9fans] Re: moving things in a window

[Theo Honohan]

In message <Pine.LNX.4.10.10009261109230.13135-100000@neon.myriadgate.net>, and
rey mirtchovski writes:
> 
> We start with a black square.
> Then we draw a white circle where the old circle was.
> Then we draw a black circle where the new circle will be.
> 
> The result is a black image with a sliver of white corresponding to
> the area of the old circle that is outside the new circle.
> 
> Interpreted as a mask, black is transparent; white opaque.
> So the mask says ``only draw where the old circle was
> but the new circle is not''.
> The final draw puts white down in those places.
> --- end paste --
> 

That matches my reading of Russ's code.  I left the masking with the
"old circle" out, in order to keep things simple.  As far as I can
see, it's really an optimisation, rather than part of the semantics of
the operation (unless switching "trails" on and off on the fly is
important to you; in general, I guessed that it wasn't).

> the explanation may be a bit too high level for you though :)

Well, I was trying to reason about a more general case, with full
RGBA objects.  

(Though I guess bringing the semantics of draw() into the argument was
lowering the *tone* a bit, groan)

Re: [9fans] Re: moving things in a window

[Douglas A. Gwyn]

andrey mirtchovski wrote:
> ... So the mask says ``only draw where the old circle was
> but the new circle is not''.
> The final draw puts white down in those places.

Of course, that clobbers other objects in the same (old) location.
I know of no way to do this right without taking into account all
potentially visible objects.  If the hardware can help (Z-buffer,
or render a model) that's great.

Re: [9fans] Re: moving things in a window

[Theo Honohan]

In message <39D23579.265E60B8@arl.army.mil>, "Douglas A. Gwyn" writes:
> andrey mirtchovski wrote:
> > ... So the mask says ``only draw where the old circle was
> > but the new circle is not''.
> > The final draw puts white down in those places.
> 
> Of course, that clobbers other objects in the same (old) location.
> I know of no way to do this right without taking into account all
> potentially visible objects.  If the hardware can help (Z-buffer,
> or render a model) that's great.

For hardware acceleration, it looks like you'd have to extend the draw
protocol with something equivalent to GLX.  

I'm not sure yet whether explicit support for double buffering, on its
own, would be a useful addition.  (See my previous message.)

Keith Packard's "render" mailing list has seen some hard-hitting
discussion of these and related issues recently.
http://XFree86.Org/mailman/listinfo/render

Re: [9fans] Re: moving things in a window

[Douglas A. Gwyn]

Theo Honohan wrote:
> In message <39D23579.265E60B8@arl.army.mil>, "Douglas A. Gwyn" writes:
> > I know of no way to do this right without taking into account all
> > potentially visible objects.

I should note that for moving a relatively small object,
quite often one doesn't have to look at *every* other
object, just those that *could* overlap.  So if one
maintains some "bounding box" coordinates for each
object, a faster scan looking for potentially affected
objects is possible.  (Typically one then assumes that
if an object is potentially affected according to this
test, it *is* affected, a conservative approach that
usually saves time.)  E.g. in my implementation of
"crabs" for the DMD/MTG I used "syndrome" words to keep
track of the crabs and handled crab-crab interactions.

Re: [9fans] Re: moving things in a window

[Douglas A. Gwyn]

Russ Cox wrote:
> I thought the neat thing about crabs was that
> the original implementation didn't do _any_
> crab-crab interaction checking.

I tried that, but when windows mere moved, etc.
it left "crab droppings".

Re: [9fans] Re: moving things in a window

[Russ Cox]

	usually saves time.)  E.g. in my implementation of
	"crabs" for the DMD/MTG I used "syndrome" words to keep
	track of the crabs and handled crab-crab interactions.

I thought the neat thing about crabs was that
the original implementation didn't do _any_
crab-crab interaction checking.

Russ

Re: [9fans] Re: moving things in a window

[okamoto]

>Aha!  There are two Kenjis!

Exactly!

One is a geologist (me), another is, probably, computer science
major (I don't know).

Kenji

Re: [9fans] Re: moving things in a window

[rob pike]

> >Kenji Arisawa wrote:
> 
> My name is Kenji Okamoto.  :-)
> 
> Kenji
> 

Aha!  There are two Kenjis!

-rob

Re: [9fans] Re: moving things in a window

[okamoto]

You are wellcome!
However, I don't want to be confused my name as another person.

Kenji

Re: [9fans] Re: moving things in a window

[Theo Honohan]

In message <20000927000801.F3F48199EA@mail>, okamoto@granite.cias.osakafu-u.ac.
jp writes:
> >Kenji Arisawa wrote:
> 
> My name is Kenji Okamoto.  :-)

Damn, sorry.  :-/

Re: [9fans] Re: moving things in a window

[okamoto]

[-- Attachment #1: Type: text/plain, Size: 174 bytes --]

So, I wrote my comment to note this technique is not so generally
applicable to want ot avoid Russ doesn't stop his effort to implement
translucent layer.  :-)

kenji


[-- Attachment #2: Type: message/rfc822, Size: 2934 bytes --]

From: andrey mirtchovski <aam396@mail.usask.ca>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Re: moving things in a window
Date: Tue, 26 Sep 2000 11:15:16 -0600 (CST)
Message-ID: <Pine.LNX.4.10.10009261109230.13135-100000@neon.myriadgate.net>

I asked Russ Cox for an explanation of the code, and I promptly received
one:
(with hopes it's useful and he doesn't mind me sending private email)

--- begin paste ---
/* clean up previous location */
if (osize && clear) {
        draw(imgmask, imgmask->r, display->black, nil, ZP);     // transparent
        fillellipse(imgmask, subpt(oldp, p1), osize, osize, display->white, ZP);        // draw opaque old
        fillellipse(imgmask, ZP, size, size, display->black, ZP);       // cover new

        draw(screen, rectaddpt(imgmask->r, p1), display->white, imgmask, imgmask->r.min);
}

We start with a black square.
Then we draw a white circle where the old circle was.
Then we draw a black circle where the new circle will be.

The result is a black image with a sliver of white corresponding to
the area of the old circle that is outside the new circle.

Interpreted as a mask, black is transparent; white opaque.
So the mask says ``only draw where the old circle was
but the new circle is not''.
The final draw puts white down in those places.
--- end paste --

the explanation may be a bit too high level for you though :)


On Tue, 26 Sep 2000, Theo Honohan wrote:
[snip]

Re: [9fans] Re: moving things in a window

[okamoto]

>Kenji Arisawa wrote:

My name is Kenji Okamoto.  :-)

Kenji