Possible CopyArea Corruption With gtkclist.




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.

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.

Thanks,


Ralph Corderoy.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]