Conference bulova::decw_jan-89_to_nov-90

I could use a pixmap as backingstore, but don't want to do this for
a widget (you never know how much of my charts will be created by the
application...).

The only stuff I found satisfactory for the moment is to do an XCopyArea,
generate an exposure with XClearArea and redraw the ENTIRE chart on
exposure. This gives a lot of overhead, but is better then clearing
the window (flicker !) and redrawing the chart. Most interesting would be to
be able to get what part of the window is not VISIBLE. 
I have looked in the reference guides for pointers to get this region,
but I haven't found any. Did I overlook something ?

Dominique

The short answer is that you need to recognize and handle the asynchronous
protocol you're generating between the client and the server.

Read up on GraphicsExpose events.  You're generating them and need to
handle them.

Imagine there is a small window covering the middle of the graph.
When the graph is partially occluded, GraphicsExpose events
are generated (by default) by the server and are sent to the client in
response to the CopyArea request.  The client must respond to these
GraphicsExpose requests by sending over a piece of the graph to
fill the "hole".

Now, if you aren't careful, the "hole" will have moved by the time
the client gets around to responding to the GraphicsExpose event,
which, in turn, had been triggered by a CopyArea request issued by the
client a relatively long time ago (a round trip to the server takes
at least 1/100 of a second).

It is easy for the client to send requests faster than the server can
handle them, and there is always a latency.  So the client has to shoot
ahead of the target, so to speak.

The best way I have found to manage this problem is to 
avoid nesting CopyArea requests.  Only have one outstanding at a time.
This helps makes the solution (shoot ahead) tractable.

Another problem to watch out for, that adds complexity, is the handling
of "normal" Expose events.  These will be caused when another window that was
only partially occluding the graph window is pushed behind the graph
window, exposing a portion of the graph window.  Do make this work
properly, while the graph is scrolling, it is important
to synchronize the response to the Expose event with the current
CopyArea request (and its possible GraphicsExpose event response).

The end result is that you need three internal variables representing
the "scroll" position of the graph.  I call them "internal", "requested",
and "external".

You might be interested in looking at the VList widget for an example
of this logic.  As a secondary advantage, the non-nesting of CopyArea
requests allows the widget to scroll much faster, since it will group
together multiple small scroll requests into a single larger one if
the server can't keep up.   Send me mail to get a VList kit.

-steve-

Thanks for your quick answer Steve. I'll have a look in GraphicsExpose.
I suppose what you told in .1 is also valid for a window obscuring
the right hand side of my graph (creating junk space where I do my
CopyArea from). If not correct me please.
As soon as I finished the widget I'll post something in dw_examples (it's
for a customized demo on process control and
online Quality Control. Maybe other people would want it also).

Dominique

>>I suppose what you told in .1 is also valid for a window obscuring
>>the right hand side of my graph (creating junk space where I do my
>>CopyArea from). 

CopyArea will fill-to-background any destination region for which the
corresponding source region is not visible.  This means that rather
than copying "junk", CopyArea will clear the region and send the
client a GraphicsExpose event specifying the destination region
that needs to be filled in by the client.

You will also want to use NoExpose events to help synchronize the
"adjustment" variables with the server state.

-steve-

Steve,

Graphics Exposure works like a charm (quark ?). I succeed in drawing
only the needed points from my graph (the one that where in the exposed
region). 

Thanks.

.5 ....works like a charm.

I have expierienced in the mean time that this works fine for "small scroll
steps". As the values for the chart come in at random x-axis intervals,
sometimes the scroll is quit big (100-500 pixels per step). I found
out that I better redraw the entire chart after the copy area. This gives
some overhead when I have NoExpose, but works smoother at GraphicsExpose.
After all the overhead is not that big, a graph with 1000 pts on it
is not really nice for the end user. So it hardly ever comes to drawing
about 100 points again.
Sorry for posting this X stuff here moderator, but as I told in my
initial entry, DECwindows_programming was down (again).

Dominique