Subject:
Re: Re: Newbie problems - clipping tutorial
From:
"Greg Haerr" ####@####.####
Date:
22 Jan 2000 20:03:21 -0000
Message-Id: <01f801bf6512$3aa56dc0$15320cd0@gregh>
: I've been tracing the behaviour of the little example I've written both in
: X11 environment and the PDA. The key of the question is clipping (as you
: wisely said :-o ), when the Desktop window gets the WM_PAINT event, the
: GdFillRect calls GdClipArea and it returns CLIP_VISIBLE in the PDA
: version, therefore in X11 version, it reaches the drawrow section of
: GdClipRect (this is the right way) .
I'm a bit confused here, since there isn't a GdClipRect. I assume you
meant GdFillRect. Anyway, yes, the WM_PAINT ends up generating
a request to GdFillRect to background fill the desktop window. Now,
it's very important here that we're tracing the background fill for
the desktop window (wp == rootwp), NOT your application window,
which will also go thru the same code sequence. So, GdFillRect
needs to determine whether the entire rectangle is visible or not,
so that it can either call the fast low level fillrect that doesn't
deal with clipping (CLIP_VISIBLE return), or, call the drawrow
function that checks each line for clipping (CLIP_PARTIAL return).
The desktop window IS obscured by your window, so it should
ALWAYS go the drawrow path. Drawrow then should draw the
background window row by row with your window clipped out.
At this point, you should probably printf() the desktop window's
clip rectangles, see below.
I've been trying to understand all
: the clipping related code, but I've got blind about it. Have you any idea?
The clipping code is actually fairly simple in concept. In the implementation,
when
we say "clip" we mean drawing is allowed, rather than disallowed. What we
do is for every point, if it is within a "clip" rectangle, then that point is
allowed
to be drawn. So, for every window, the system keeps an array of rectangles,
called clip rectangles. These rectangles represent areas that are allowed to
be drawn. Now, imagine your X11 screen. The total set
of all window's clip rectangles completely "tiles" the screen. More precisely,
the clipping rectangles for all windows NEVER overlap, but precisely
describe the ENTIRE screen real estate, with each window containing as
few rectangles as required to describe it's viewable area. Got it?
So to start, each window is given a clip rectangle equal to the intersection
of the physical screen and it's complete window area. Then, windows
above in z order to your window are "subtracted" from your first rectangle.
This means that your first clip rectangle becomes more rectangles: as many
as is required to "tile" your viewable window area.
WinSetClipWindow in winclip.c builds the clipping rectangle area for a given
window. WndExcludeClipRect subtracts a rectangle from another rectangle,
possibly generating up to 4 new rectangles (think about it). GdSetClipRect
in devclip.c sets up a global cliprect array so that the GdClipArea and
GdClipPoint routines work quickly. I am actually rewriting all this and
bringing new code based on X11's cool "y-x-banded" realloced
clipping regions, which work basically the same way, but don't
require a global cliplist, and are optimized for speed by sorting
each rectangle in a window's cliplist first by y then by x. (read
devrgn.c, it's very cool X11 code)
:
: The other missfunction is that when a window is dragged around the screen,
: the shapes that are drawn around the screen aren't cleared. I'll try to
: explain: in X11 version, only one shape at a time is present; in the PDA
: version, there are a lot of shapes of the screen at a time, and they are
: only cleared when the pen is released, and everything is cleared because
: of the last paragraph stuff.
I'm wondering if there's not some strange bug in your pen code, since
everything happens when the pen is released. Otherwise, perhaps
we have an endian problem, although I thought others reported that
it works on a Solaris system.
Also, you might want to compile in the XORMOVE window
move algorithm, rather than what you're using.
Regards,
Greg
