Re: Possible CopyArea Corruption With gtkclist.

[Owen Taylor <otaylor redhat com>]

ralph@inputplus.demon.co.uk writes:

> Hi,
> 
> I've been having some problems with some of my own X code and looked
> towards gtk+-1.1.1's gtkclist.c for inspiration but it might have the
> same problem.
> 
> The problem with vadjustment_value_changed using a CopyArea request to
> shift part of the list when scrolling is you can't be sure that of the
> state of the source area that is being copied.  I understand the use of
> check_exposures and gdk_event_get_graphics_expose in processing any
> GraphicsExpose or NoExpose events that may result from the CopyArea but
> this doesn't always seem sufficient.  Here's an example.
> 
>     1.  The list window is partially obscured by another window which
>     is then removed.  The server generates an expose event that starts
>     winging its way towards the client.
> 
>     2.  Meanwhile, the list decides to scroll and issues a CopyArea
>     request which happens to intersect with the area that has been
>     exposed (but hasn't been redrawn yet).  It then waits for either
>     one or more GraphicsExpose events or a NoExpose event on that
>     window.
> 
>     3.  The server processes the CopyArea request and sends a NoExpose
>     event in reply.  Unfortunately, part of the source area contained
>     nothing but the background colour and that has now been copied.
> 
>     4.  The list receives the NoExpose event.  It then sends requests
>     to redraw the new blank area that has been scrolled into.
> 
>     5.  The expose event is processed by the list;  requests are sent
>     to redraw the rows in the exposed area.

Yes, this sequence can happen. But it will be very rare with the CList.
 
> The end result is that the list now contains an area that was copied
> before its contents were valid, but since it wasn't obscured when the
> CopyArea was processed, no GraphicsExpose events were generated for
> it.
> 
> This can happen in my own client which happens to have a structure very
> similar to gtkclist.c.  I haven't tried with an actual gtkclist but
> can't see any reason why this shouldn't also suffer the same problem.
> 
> Can anyone explain why this isn't a problem with the gtkclist widget?
> I can't see a solution that copes with all cases.

How often do you move a window over the CList while simultaneously
scrolling the window. The only time this is ever going to be a problem
for the CList is if your program isn't keeping up with the incoming
events, or perhaps if your machine is thrashing. 

(Are you say, continously auto-scrolling without user interaction? - I
suppose that could trigger the problem - though typically in 
this circumstance any corruption will very quickly be off the 
screen...)

There is only one algorithm I know of which is absolutely foolproof,
and this would pretty much need to be implemented at the GDK level.

* Each X event has a Serial # which refers to the last request made
  by the application. Every time the application makes an XCopyArea
  request, it is stored on a queue with the request number. 

* When an Expose or GraphicsExpose event is received, it is translated
  through all XCopyArea's in the queue that have serial number after
  that in the event strucutre.

* When the NoExpose or count=0 GraphicsExpose event corresponding
  the the XCopyArea is processed, then the XCopyArea is removed
  from the buffer. 

This could be implemented in GTK+ pretty easily - but it hasn't
been a high priority since this type of problem is, in normal
usage, extremely rare. It will probably be done at some point
since it sort of neat, in any case.

[ Actually there is another way to get it absolutely correct - 
  XGrabServer ;-) ]

Regards,
                                        Owen