Conference bulova::decw_jan-89_to_nov-90

>    One useful application of this is to build a region with the visible
>    parts of a window and set it as the clip mask. You can even check if
>    the things you have to draw belong to this region and not call Xlib at
>    all when this is not the case.
 
The server will clip output to the visible window anyway, and by supplying
yet another (redundant?) clip mask, the server will only have to do the
work twice.  So doing XSetRegion doesn't seem appropriate if all you're
doing is to set the clip mask to what's visible.

On the client-side, however, it may be useful to put code in the application
that tries to avoid sending draw requests to the server that apply purely
to invisible regions of the window.  Generally, the width/height of the
output window is sufficient and further clipping (to handle the case
of partly occluded windows) has limited payback.  Generally...

>    The only problem with this is that I did not find a way to gather the
>    list of visible areas of a window to build such a region. If someone
>    has any idea, I will be very pleased to hear it ...

If you really really have to know exactly what is visible, you can always
XClearWindow and watch the ExposeEvents as they come back.  This will be
a list of the visible regions of the window but is destructive to the
window contents.  If you get a little tricky, you can do this
non-destructively:

	XGrabServer...			/* avoid being interrupted */
	XSetBackground (..., None)	/* set background to none */
	XCopyArea (...)			/* copy offscreen to entire window */
	XSetBackground (..., ...)	/* set it back to normal */
	XUngrabServer...		/* and atomic operation is done */

You'll get a cascade of GraphicsExpose events for the exposed regions.
Or a NoExpose event if nothing is visible.

Since you're copying from offscreen, but you've set the window 
background to None, the window contents will not be affected.  All
this will do is to generate the GraphicsExpose events and return.

>    One related thing I have found weird on DECWindows is that ConfigureNotify
>    events don't get signaled to the application for all the cases
>    described in the MIT Xlib documentation when used as a translation for
>    a window widget. I could have my action routine called only when the
>    window is resized (it should normally be called when the window size,
>    position, border and/or stacking order is changed).

Can you be more specific.  I haven't seen any problems with ConfigureNotify
events.

-steve-

Thank you very much for the answer.
    
>>    The only problem with this is that I did not find a way to gather the
>>    list of visible areas of a window to build such a region. If someone
>>    has any idea, I will be very pleased to hear it ...

> If you really really have to know exactly what is visible, you can always
> XClearWindow and watch the ExposeEvents as they come back.  This will be
> a list of the visible regions of the window but is destructive to the
> window contents.  If you get a little tricky, you can do this
> non-destructively:

> 	XGrabServer...			/* avoid being interrupted */
>	XSetBackground (..., None)	/* set background to none */
>	XCopyArea (...)			/* copy offscreen to entire window */
>	XSetBackground (..., ...)	/* set it back to normal */
>	XUngrabServer...		/* and atomic operation is done */
>
> You'll get a cascade of GraphicsExpose events for the exposed regions.
> Or a NoExpose event if nothing is visible.

> Since you're copying from offscreen, but you've set the window 
> background to None, the window contents will not be affected.  All
> this will do is to generate the GraphicsExpose events and return.
    
    Thanks for your example; I just hope that it will not take longer than
    sending everything. I am in a typical situation where doing this can
    really be interesting (graphics intensive application); moreover I am
    also using a crosshair which is drawn with the Xor GC function, and I
    need to clip it to the visible areas, otherwise when the occluded
    parts become exposed, moving the mouse make the crosshair leave traces.
    
>>    One related thing I have found weird on DECWindows is that ConfigureNotify
>>    events don't get signaled to the application for all the cases
>>    described in the MIT Xlib documentation when used as a translation for
>>    a window widget. I could have my action routine called only when the
>>    window is resized (it should normally be called when the window size,
>>    position, border and/or stacking order is changed).

> Can you be more specific.  I haven't seen any problems with ConfigureNotify
> events.
    
    Let's define a window which is controlled by a main_window (in UIL).
    This window has a translation for the ConfigureNotify event. In the
    corresponding action routine, I just printf ("It did it"). You can see
    easily that the action routine is only called when you resize the
    window. 


    Thanks again for the help
    Maya

>>    One related thing I have found weird on DECWindows is that ConfigureNotify
>>    events don't get signaled to the application for all the cases
>>    described in the MIT Xlib documentation when used as a translation for
>>    a window widget. I could have my action routine called only when the
>>    window is resized (it should normally be called when the window size,
>>    position, border and/or stacking order is changed).
    
>    Let's define a window which is controlled by a main_window (in UIL).
>    This window has a translation for the ConfigureNotify event. In the
>    corresponding action routine, I just printf ("It did it"). You can see
>    easily that the action routine is only called when you resize the
>    window. 

This I can explain.  The main_window widget is NOT reconfigured when you move or
restack its SHELL.  And, in fact, it is the window manager's frame window that
is really being moved or restacked.  Thus it is the main_window's grandparent
that would get the ConfigureNotify events.  And this depends on which
window manager you're running.  The main_window is always at position 0,0
(or thereabouts) within its shell, and, since it has no siblings, its
stacking order is not relevant.

Resizes, however, are propagated through to the main_window as you might
expect.  

-------

As far as having to clip while drawing the crosshair, I guess I don't
understand your problem exactly.  Isn't there a GC option (includeInferiors
or ClipByChildren or something like that) that would control the effect?

-steve-

    
    Thanks for the ConfigureNotify information. I am using the standard
    Ultrix/Risc Decwindows Manager. I will try to play with an event
    handler for the main_window grandparent.
    
    I reread the documentation about the ClipByChildren and
    IncludeInferiors subwindow modes. My understanding is that these modes
    apply only to subwindows of the drawing window. In my situation, the
    window has no children at all. I want to clip against other application
    windows which are partially obscuring my drawing window.
    

    Thank you very much for the help
    Maya

>> I want to clip against other application
>>    windows which are partially obscuring my drawing window.

But this is the default behavior.  It is very difficult,
in fact, to write into another application's window, even if
it is partially occluding your drawing window.

Do you have reason to believe there really is a problem?
I think you may be looking for a solution to a non-problem.

-steve-

        
    Of course, it is the way things happen. May be I was not very clear.
    
    When you draw something in XOR mode which can be big enough (like a
    crosshair) to have a chance to be occluded by other windows, if the
    window configuration changes, erasing the crosshair does draw it in
    fact in newly visible areas.
    
    What I want to do is to know when and how the configuration changes, so
    I can take care of this situation.
    
    Also, since I am managing my own display list, I am capable of
    detecting if it is useful to call Xlib for drawing and since I am
    drawing a lot, I want to minimize those calls.
    
    
    About setting a ConfigureNotify event handler on the grandparent of the
    main window, I tried to do it. There are 2 problems :
    
    - The main window does not have a grandparent, just a parent which is
    the toplevel widget.
    
    - I added an event handler for the toplevel widget on the
    StructureNotify and SubstructureNotify event masks without any more
    success. I am still investigating in this area, because I may not have
    done it the right way.


    Thanks a lot for the help
    Maya

    
>    - I added an event handler for the toplevel widget on the
>    StructureNotify and SubstructureNotify event masks without any more
>    success. I am still investigating in this area, because I may not have
>    done it the right way.
    
    I could not make this work better, ie I am not getting called when
    my window is restacked. The events which do the call are :
    ReparentNotify, MapNotify and ConfigureNotify when the window is
    resized. When the window is moved I get client messages type 74 and 79
    which are not defined in Xatom.h (but I do not really care for this
    event).

    thanks and regards
    Maya

>    When you draw something in XOR mode which can be big enough (like a
>    crosshair) to have a chance to be occluded by other windows, if the
>    window configuration changes, erasing the crosshair does draw it in
>    fact in newly visible areas.
>    
>    What I want to do is to know when and how the configuration changes, so
>    I can take care of this situation.

What's wrong with normal Expose events?  That will tell you about any newly
visible areas.

Still with you and hoping that there's an easy answer...

-steve-

PS: The "grandparent" window does not have a widget in your application
context.  You would have to make server calls to get the window ID.
You cannot get to it by chasing up your widget hierarchy.

Thanks a lot for the help.
        
>>    When you draw something in XOR mode which can be big enough (like a
>>    crosshair) to have a chance to be occluded by other windows, if the
>>    window configuration changes, erasing the crosshair does draw it in
>>    fact in newly visible areas.
>>    
>>    What I want to do is to know when and how the configuration changes, so
>>    I can take care of this situation.

> What's wrong with normal Expose events?  That will tell you about any newly
> visible areas.
    
    Normal Expose events allow one to redraw on the newly visible areas.
    What I want to do is to not erase my crosshair in these areas because
    it would be really drawn (using the Xor GC function).
    
    I was thinking of a simpler way than tracking Expose events in my
    pointer motion action procedure. My original intent was to clip my
    crosshair with the visible areas and erasing it when the configuration
    changes (with the old clipping region) before recomputing a new
    clipping region according to the new visible area and redrawing it
    after that with the new configuration.
    
    
    Thanks for your information on the grandparent window. I will try it
    this afternoon.


    best regards
    Maya

>    Normal Expose events allow one to redraw on the newly visible areas.
>    What I want to do is to not erase my crosshair in these areas because
>    it would be really drawn (using the Xor GC function).
>
>    I was thinking of a simpler way than tracking Expose events in my
>    pointer motion action procedure. My original intent was to clip my
>    crosshair with the visible areas and erasing it when the configuration
>    changes (with the old clipping region) before recomputing a new
>    clipping region according to the new visible area and redrawing it
>    after that with the new configuration.

	I think you can do better.

	Rather than clip all your normal operations to the last configuration
	known to the application, you might be better off letting all normal
	writes proceed unclipped.  Instead, only clip the processing of
	Expose events to the (single) region specified in the Expose event
	itself.  Do an XClearArea as the first thing in the Expose routine
	to ensure that the region being redraw is clear.  This XClearArea call
	gets around any possibility that an unclipped (normal) draw
	operation wrote into the exposed region because of an timing overlap.

	The Expose routine can depend on the region it is drawing into being
	clear (because it cleared it itself), and by clipping only the draw
	operations done as a result of the Expose event, you can ensure
	that other portions of the window will not be affected.

	This way, you do not have to track the window configuration at all.

-steve-

    
>    Thanks for your information on the grandparent window. I will try it
>    this afternoon.
    
    One more problem : I am using XtMainLoop() and callbacks for the events
    I want to process. Since I have to select the StructureNotifyMask for
    the grandparent window at the Xlib level, how can I have the X toolkit
    event dispatcher call me back ?
    
    Note : I still want to do it that way because I want to clip
    internally my display list with visible areas for maximum
    performance in initial drawing and window refresh (this a *very* 2D
    graphic intensive application so I do not want to talk to the server
    unnecessarily).


    Thank you very much for the help
    Maya

>    One more problem : I am using XtMainLoop() and callbacks for the events
>    I want to process. Since I have to select the StructureNotifyMask for
>    the grandparent window at the Xlib level, how can I have the X toolkit
>    event dispatcher call me back ?

I know two solutions to this one.  Naturally, I take the road less traveled,
but I'll give the standard answer first.

(1) Don't use XtMainLoop.  Break it up and intercept all events.  This is
hard, especially because when you are in a modal state, you are not
going through XtMainLoop anyway.  It also hurts code modularity.

(2) Use a PseudoWidget.  I haven't posted it yet but I have a widget that
takes a window ID as a resource and allows you to glom event handlers, etc,
onto someone else's window.  Rather than creating its own window, it uses
the window ID supplied to it and fools the toolkit intrinsics into dispatching
events for that window to the PseudoWidget.  This allows you to continue
to use XtMainLoop and seems a much cleaner solution.

If anyone is interested in this PseudoWidget, I will be happy to send it out.
It is still pretty primitive (undocumented) but I find it very useful to
help with hacks like this one.  It also makes it easy to do things like
put popups on the root window, etc.

-steve-

    
    I am definitely interested in it or anything which can solve my problem
    without breaking code modularity and application modeless style.
    
    Thank you very much for your help.

    best regards
    Maya

    Sorry, my mail address is Maya DAN @PAO or 48296::DAN_M
    thanks a lot
    Maya