Re: pop-forum Overlapping moving picture objects [Was: progress dots in ved]

Aaron Sloman <A.Sloman@xxxxxxxxxxxxx> wrote:

Apologies for delayed response:

No need!

On Mon, 10 Mar 2008 Jonathan L Cunningham wrote:

[JLC]
I am not using 'xor' to erase objects at all. I'm aware of the problems
this causes.

The approach I am using is intrinsically safer and more robust.

The main reason I used XOR was to allow movable pictures to have any
shape at all including having holes. This allows sliders to be

This is even simpler with my approach.

diagonal or circular for example, instead of being restricted to
horizontal and vertical. In fact, any 2-D picture that can be drawn
by a collection of RC_GRAPHIC commands can be made movable, though
movements can look odd when such a picture moves over something that
is not white, because of the use of XOR rather than re-painting bits
of the window.

I'm not sure why you think XOR makes this more possible. The approach I
am using is to draw, when something moves, everything in its new
position.

That is *everything*. It doesn't matter whether they have holes,
transparent interiors or what. If *everything* gets redrawn, then all
that matters is that objects can draw themselves.

Of course, you only need to redraw things that have changed -- but you
can err on the side of caution. If in doubt, draw every single thing
which is visible anywhere in the window.

Actually, most windowing systems have a "clipping region". Drawing an
object which is not inside the clipping region is very cheap. So you
*can* redraw everything, as a first approximation. That's (currently)
what I'm doing. It works fine. At some point, I will have to see how
many objects it takes to make it slow down enough to be noticeable.

[JLC]
When you update the position of an object, it tells the window that
everything in its old position needs to be redrawn, and everything in
its new position needs to be redrawn. At some convenient time, but
before the window is repainted, the OS erases both rectangles, which may
overlap, and then asks all the affected objects to redraw themselves.

This is more expensive than the old 'xor' approach - but machines are
much faster nowadays. The worst that will happen will be some
flickering, and I will eventually implement double-buffering (in the C++
layer) to prevent that.

I could not tell from that whether you were assume that all picture
objects are rectangular or whether the rectangle is just the
bounding box of a picture.

The bounding box is what is passed to the OS as needing to be redrawn. I
could just mark the entire window as needing to be redrawn, but by using
the bounding rectangle, it becomes cheap to redraw things which are
outside the area affected (because the OS ignores drawing commands in
those areas, and only draws what needs to be drawn).

If I have understood this correctly it requires the system to
remember which objects are behind which others, so that re-painting
is done in the right order.

I am not sure what you are saying here. Yes, the objects are drawn
oldest first, unless the Z-order is explicitly changed.

So if you want a rectangle around some text, then you must draw an
opaque rectangle before you draw the text. On the other hand, if you
draw a rectangle with a transparent interior, it doesn't matter which
order you draw the text and the rectangle.

In RCLIB the objects in a window are
totally ordered (though the same object can be shown in more than
one window, and can be covered in one window and visible in
another.)

Objects are totally ordered in my system, too.

It might be better to have a partial ordering, so that, for example,
it is specified that the long horizontal object is in front of the
two shorter objects, but the relative depths of the two shorter
objects is not specified:

|--|
| | |--|
|-------------------------------|
|-------------------------------|
|--| |--|

I have not thought this through, however.

A few years back, I was trying to write a game (in C++) with little
animated robots running around, and the test for whether one object was
in front of another (occluded it) was very complex. I forget the details
- I must dig out the old code and have another look at it, to remind
myself of the issues.

Since the objects moved about, the ordering needed to be updated as
they moved.

I do remember that I wrote a routine called "posort" (partial-order
sort). But I can't remember why it was necessary! Possibly because you
could have not(a < b) and not(b < a), yet (a < c < b). Or something.

(E.g. neither a occludes b, nor b occludes a, but a occludes c, and c
occludes b. So they must be drawn in the order c,b,a. Most sort routines
assume that you can directly compare a and b ...)

I must dig out the old code and have a look at the comments in it. :-)

One of the things I have found extremely annoying on my wife's
Windows XP machine is that no window can be moved partly off the
screen to show more of a partly covered window.

Is that in some particular application? I've never experienced this
restriction with anything I've done in Windows XP.

Is that because
microsoft programmers did not know how to implement that? I use that
all the time with the X window system on Linux: it is FAR more
convenient than having to resize a window to show more of another
window. But it does require being able to move a window when its
title bar is off the screen. I use ALT+Left button for that.

I hope your system will not inherit such MSwindows restrictions.

There is no such restriction that I'm aware of. You can't (I believe)
move a window *completely* off-screen. But that makes sense: how would
you get it back? (Yes, the Linux/unix multiple desktops is a much better
idea - but given a single desktop, it makes sense not to lose windows
permanently.)

It's possible that there is an "easy" or "beginner" mode preventing
windows being moved. If so, it can be turned off.

Jonathan
.

Relevant Pages

  • Re: CUPS/Samba help please
    ... Now, based upon my experiments, whenever the display is redrawn, the print ... driver itself communicates with the CUPS machine to redraw this little window. ...
    (Debian-User)
  • Re: how to use the GetClipBox and redraw the particular rectangle
    ... CRect rectUpdate; ... > actually i need to draw a rectangle in the view window.. ... > then i need to clip the rectangle and need to redraw it.. ...
    (microsoft.public.vc.mfc)
  • Re: Mouse movement within CStatic/Picture box
    ... over the picture box, I was wondering if you guys can suggest a method ... where I can refresh the picture box or reset the previous rectangle, ... draw a blank background rect to "fix" an empty box. ... of the other popup window will remain. ...
    (microsoft.public.vc.mfc)
  • Re: colored rectangle and scrolling form
    ... When I scroll ... The form is bigger than the window: ... Since you are using the window width to draw your rectangle, ...
    (microsoft.public.vc.mfc.docview)
  • Re: Mouse movement within CStatic/Picture box
    ... over the picture box, I was wondering if you guys can suggest a method ... where I can refresh the picture box or reset the previous rectangle, ... draw a blank background rect to "fix" an empty box. ... of the other popup window will remain. ...
    (microsoft.public.vc.mfc)