nanogui: Thread: Re: Newbie problems - clipping tutorial

: 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

On Sat, 22 Jan 2000, Greg Haerr wrote:

> I'm a bit confused here, since there isn't a GdClipRect.  I assume you
> meant GdFillRect.  
I'm sorry, I was thinking about GdClipArea.

I expended more time looking at the code, and I've got my terrible
mistake. The clipping works OK, but I defined my SCREENDEVICE as
PSF_MEMORY. This was the only reason. 

On the other hand, I've just fixed the matter with the window shapes being
painted all around the screen. The problem was the implementation of the
drawing routines with gr_mode==MODE_XOR. I've been looking at the code in
fblinX.c; the way it is implemented is:
*addr = (*addr & notmask[x&1]) ^ (c << ((1-(x&1))*4))

this way, you are erasing the bits of the point you are XORing, before
XORing it. So, if you XOR it again, you are not restoring the value of the
original point. I've implemented it this way:
 *addr=(*addr&notmask[x&1])|((*addr ^ (c<<((1-(x&1))<<2))) & ~notmask[x&1]); 

now, you are ORing the other points part of the byte with the XORed
point. If you repeat the operation over the byte, you will get the
original byte.

> 
> 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.

Yes it works. I've tested it.

Well; the next thing I want to do is fixing the color representation (it's
a 4bpp/2bpp/1bpp grayscale screen 160x160). I have seen that the colors
are very different than the expected (a dark gray when it should be a
light gray). I think that the right way to fix this is writing a new
devpalXXX.c, isn't it? I've tested the devpalgray4.c instead of devpal4.c
but the result is very light and I can hardly see the windows.

One more time, thanks a lot. It looks great now (but the colors).

Best regards.
Manolo.

: On the other hand, I've just fixed the matter with the window shapes being
: painted all around the screen. The problem was the implementation of the
: drawing routines with gr_mode==MODE_XOR. I've been looking at the code in
: fblinX.c; the way it is implemented is:
: *addr = (*addr & notmask[x&1]) ^ (c << ((1-(x&1))*4))
: 
: this way, you are erasing the bits of the point you are XORing, before
: XORing it. So, if you XOR it again, you are not restoring the value of the
: original point. I've implemented it this way:
:  *addr=(*addr&notmask[x&1])|((*addr ^ (c<<((1-(x&1))<<2))) & ~notmask[x&1]); 
: 

Wow.  So none of the MODE_XOR portions of the fblinX.c drivers have
been working?  Send me your fixed fblinX.c file, and I'll update the
rest.  I assume you've fixed both drawpixel and the draw{vh}line
stuff as well..  Also, you might use "mask[]" instead of "~notmask[]" so that
doesn't have to be computed each time...


: Well; the next thing I want to do is fixing the color representation (it's
: a 4bpp/2bpp/1bpp grayscale screen 160x160). I have seen that the colors
: are very different than the expected (a dark gray when it should be a
: light gray). I think that the right way to fix this is writing a new
: devpalXXX.c, isn't it? I've tested the devpalgray4.c instead of devpal4.c
: but the result is very light and I can hardly see the windows.

Yes, a devpalXXX.c that better matches the color scheme in wingdi.c
just before the sysColors array is defined.  You might want to define
another color scheme for 16 color gray...  Otherwise the system colors
are matched with the closest palette colors, and the matches may not
match well.

Regards,

Greg